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

维基百科,自由的百科全书

这是本页的一个历史版本,由Sanmosa留言 | 贡献2019年5月31日 (五) 09:09 (VIA W+编辑。这可能和当前版本存在着巨大的差异。

此頁面探討维基百科的方針與指引


請注重礼仪、遵守方針與指引,一般問題請至互助客棧其他區知识问答提出,留言后请务必签名(点击 )。


發表前請先搜索存档,參考舊討論中的内容可節省您的時間。
公告欄
# 💭 話題 💬 👥 🙋 最新發言 🕒 (UTC+8)
1 提議提高條目評選投票資格門檻 1 1 Sanmosa 2024-05-14 19:00
2 再擬議立國際關係命名常規為方針 49 10 Sanmosa 2024-05-12 22:19
3 修订删除方针明确允许删除没有来源30日以上的条目 54 9 August0422 2024-05-09 18:22
4 提議英維指引en: MOS:TVINTL經本地化後引入中維維基百科:格式手冊/電視 74 8 HK5201314 2024-05-13 11:25
5 提议:允许使用开放代理编辑WP:RFR,并在WP:RFR中加入“注册账号申请” 1 1 Sanmosa 2024-05-14 19:01
6 提议:对WP:日常计算做小修改 1 1 Sanmosa 2024-05-14 23:49
7 提议对中国大陆的文物保护单位设立关注度豁免 1 1 Sanmosa 2024-05-14 23:01
8 附带有限追踪检查的无IP的IPBE 12 7 魔琴 2024-05-12 22:18
9 关于国籍的原创研究 19 7 Ericliu1912 2024-05-14 01:04
10 关于跨行政区域的实体,是否应该使用多个分类 15 6 克勞棣 2024-05-15 01:00
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時,
請先檢查設定是否有誤

正在廣泛徵求意見的議題

以下討論需要社群廣泛關注:重新整理

維基百科格式與命名

Template talk:Infobox person § 修改 Infobox person 中 native_name 参数位置

維基百科方針與指引

Wikipedia talk:共识 § 共識建立的遞進步驟

Wikipedia talk:關注度 (文化遺產) § 提议对中国大陆的文物保护单位设立关注度豁免

Wikipedia talk:关注度 (地理特征) § 建議將地理特徵關注度指引中有關道路的部分改為在交通關注度指引中列出

Wikipedia talk:非原创研究 § 提议:对WP:日常计算做小修改

維基百科提議

Wikipedia talk:仲裁委员会 § RfC:2024年2月

Wikipedia talk:字詞轉換處理/公共轉換組 § 思路:條目預儲公共轉換組中匹配的規則,減少載入時間

Template talk:Twitter § Twitter改為X

Wikipedia:互助客栈/其他 § 对ITN获选标准及ITNR的小修订

Template talk:Hang on § {{hangon}}

提議設立WP:IINFO內容改善流程

目前討論狀態:

--宇帆留言·歡迎簽到R₁R₂NKC2019年3月1日 (五) 14:10 (UTC)[回复]

(更新) --宇帆留言·歡迎簽到R₁R₂NKC2019年4月26日 (五) 07:21 (UTC)[回复]
原標題為提議設立愛好者內容改善流程,見最下方爭議,改為更沒有爭議的標題--宇帆留言·歡迎簽到R₁R₂NKC2019年5月6日 (一) 10:39 (UTC)[回复]

近期出現了許多提刪,稱條目通篇愛好者內容需要刪除,例如這個,但都是直接提刪,完全沒有先給編者一點改善時間,對一些經驗較少的編者往往措手不及。因此建議參考關注度指引:

建立一個粉絲愛好者內容通告模板,確保此模板有放在條目足夠的時間,使主編知悉條目的WP:PLOT後再予提刪,同時也可以避免到一些不友善新手的問題。期實施方式可以比照小小作品流程,透過分類追蹤,若30天後仍通篇粉絲內容再提刪,爭議會比較小,也可以減少對於部分維基新手的傷害。 存廢討論頁只需加個批次提刪章節「30天後仍通篇愛好者內容的條目」統一討論這類條目。

因為實在不認為這個過多愛好者內容的條目一出現就秒提刪是一個好的現象,關注度不足都有30天緩衝,目的是讓主編熟知問題,並有充分的改善時間,而愛好者內容亦是,並不是所有目前充滿愛好者內容的條目都無改善空間的。

以上提議。邀請希望解決維基WP:PLOT問題的熱心用戶U:AINH參與討論。--宇帆留言·歡迎簽到RiMu·Ru2019年2月17日 (日) 22:06 (UTC)[回复]

違反WP:IINFO的30天清理流程部分

釐清WP:IINFO最大限度

注意:本段落包含許多{{bot-directive-archiver|no-archive-begin|talkHF}}<!--不要移除此行--><!--不要移除此行-->{{bot-directive-archiver|no-archive-end|talkHF}},請手動存檔時將此區間全部文字移除再存檔-- Sunny00217 - 2019年5月25日 (六) 12:41 (UTC)[回复]

(:)回應:我覺得沒有必要這樣搞。--宇帆留言·歡迎簽到R₁R₂NKC2019年5月31日 (五) 08:16 (UTC)[回复]

其他議題

Wikipedia:關注度 (虛構事物)

合并最快,就条目内容而言,合回主条目,最多是另条目质量下降而需要时间改善,独立出来就要考虑关注度作为条目存在门槛的要求。关于分割部分就是放了这么久考虑出来的。——路过围观的Sakamotosan | 避免做作,免敬 2019年2月18日 (一) 12:45 (UTC)[回复]
請問目前指引出那一條可推導出「盾之勇者成名錄角色列表應合併回主條目」?我覺得目前這部分描述不太清晰。角色列表,世界觀列表是否必須有獨立的關注度?我個人則認為這兩者是關注度可繼承自主條目的特例,所以我上面不要求存在獨立的第三方來源。但是,支持獨立列表的最低來源要求又是什麼呢?--Temp3600留言2019年2月19日 (二) 13:53 (UTC)[回复]
因为这部分是由主条目分割出来,如果不能被独立保留,为了令作品的剧情描述完整,合并回去或者恢复是较好的方法。法棍预警+常识。现有规则对于列表的独立存在似乎不明确,列表的分割又是这类虚构作品或事物经常出现的情况,而且存在条目间关注度不能相互继承(除非能为此例打破规则),如果我认为的话,还是至少部分项目有来自于作品描述的一手来源(但不限于此),且部分项目存在符合关注度来源要求的对其的评价等。——路过围观的Sakamotosan | 避免做作,免敬 2019年2月20日 (三) 01:02 (UTC)[回复]
角色評價。你認為目前有那些條目擁有符合關注度要求的外部評價呢?如何通過指引,哪些目前存在的獨立角色列表需要被刪除呢?--Temp3600留言2019年2月20日 (三) 05:21 (UTC)[回复]
不讨论个案。另外我的做法是一般情况下不溯旧,新条目按新做法,对于过往条目的话,非要弄的话还是那个原则:整理,篇幅,讨论。——路过围观的Sakamotosan | 避免做作,免敬 2019年2月20日 (三) 07:08 (UTC)[回复]
你的意思是否等於「所有目前存在的角色列表都符合指引的規定」?還是有其他安排?--Temp3600留言2019年2月20日 (三) 08:10 (UTC)[回复]
我的原则上是“Careful, Chief. You dig up the past, all you get is dirty.” 囧rz……,非要较劲的话,有合适来源或者篇幅不适合合并的话就算了,没有的话能合则合。当然最好就是不要挖旧账,除非能好好地善后。。——路过围观的Sakamotosan | 避免做作,免敬 2019年2月20日 (三) 09:57 (UTC)[回复]
我在原則上同意你的見解。為了明文化這一方面,我提議設立一年緩衝期,2020年後方可提刪現存的角色/世界觀等拆分列表。你看如何?--Temp3600留言2019年2月21日 (四) 11:44 (UTC)[回复]
设限期就没必要了,大把没来源的都没人管,专门花心思管这个?我觉得管,没问题,但是如果像SM那样洪水般的做法肯定会被抵触,偶然发现一条算一条都不是问题。——路过围观的Sakamotosan | 避免做作,免敬 2019年2月21日 (四) 13:24 (UTC)[回复]
  • 对于"Is this TV series even notable?",应该是指对于来源的使用导致判断关注度的问题?这个条目的确有些问题,过于依赖一手性质的来源(不清晰的本书说明引用,和来源于改编播放组织的评价)。我认为虚构作品及事物,既要有由一手或二手合要求来源描述其本身和剧情描述,更重要的有二手的合要求来源描述其对现实的影响或现实对其的评价(例如说明销量或者因为销量而产生的评价等)。——路过围观的Sakamotosan | 避免做作,免敬 2019年2月18日 (一) 02:14 (UTC)[回复]
拆分合并问题,并不影响整个Wikipedia:關注度 (虛構事物)的通过吧?如果仅仅是拆分合并问题上无法达成共识,那么在指引中把它注明一下就可以了。不应该仅仅为了其中一小部分问题,而把整个指引废掉--百無一用是書生 () 2019年2月19日 (二) 03:58 (UTC)[回复]
拆分列表是虚构作品类经常出现的问题,而且本来已有的方针指引中对列表的态度仍然不太完善,所以单独在这个系列上做操作完善。不过原则上已经说明应该怎样操作。对于其他部分不知道有没疑问?这玩意16年定初稿,讨论剩下列表部分,已经够长了。 囧rz……——路过围观的Sakamotosan | 避免做作,免敬 2019年2月19日 (二) 08:15 (UTC)[回复]
拆分列表問題是這類條目的核心問題,繞過它的指引我覺得意義不大。--Temp3600留言2019年2月19日 (二) 13:53 (UTC)[回复]
  • 兩件事:於「虚构作品」下添「獨立列表」一項,列明每個二級標題下面最少需要一個第一方來源,證明所寫的人物群/設定群確實存在。評價部分未想好如何規範。
  • 列明跨媒體作品需得到獨立第三方介紹方可分柝特定媒介的頁面。--Temp3600留言2019年2月22日 (五) 17:30 (UTC)[回复]
@Temp3600,后者已补充。对于独立列表,主要要考虑从一个整体将其细项单独分割出来的列表条目是否与其整体条目有相连的关注度要求,如果相连的话,则视列表条目是整体条目的延伸而关注度由整体条目声明。还是前言,本社群对列表条目的存在还是不够明晰,导致了许多类似XX人列表、剧情列表类似的存在而且有容许这些条目的存在。——路过围观的Sakamotosan | 避免做作,免敬 2019年2月24日 (日) 08:10 (UTC)[回复]

维基百科:日本動漫遊戲條目指導「故事簡介」小節立為指引

建議討論動漫條目中那些項目算是支節。可以先列出數個良好條目,用來當標準。--Temp3600留言2019年2月18日 (一) 09:01 (UTC)[回复]
想問問@Cwek對這個方案的看法。--Temp3600留言2019年2月18日 (一) 14:08 (UTC)[回复]
  • 小圓角色列表的前半部分寫得不錯,就是後半那些只有角色名的段落比較糟糕,寶可夢列表雖然有設計也有評價,但它的格式和一般角色列表差了不少,不然這兩個應該也可以做為參考範例。-KRF留言2019年2月18日 (一) 23:17 (UTC)[回复]
  • 如果有留意过相关讨论页的话,这个指导我是不太支持的,因为它废除了一些在翻译日文条目时一些简便写法,实际上加大了条目初始建设的难度,也怕有人以此鸡毛当令箭。当然如果有参与GA的话,这个指导有必要参考。——路过围观的Sakamotosan | 避免做作,免敬 2019年2月19日 (二) 01:48 (UTC)[回复]

希望中文維基百科能設立正式的把愛好者內容轉移到第三方Wiki的制度

討論時間過長問題

防存档。Σανμοσα 2019年5月25日 (六) 04:49 (UTC)[回复]

Wikipedia:頁面分類 关于用户页分类和草稿分类 的修改

命名常规方针中的罗马化规则与部分日本人物的条目命名

羅馬化優先,待修正方針。剩餘討論請見下方。MeritTim 2019年5月25日 (六) 12:36 (UTC)[回复]
下列討論已經關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。

原标题为:急:WP:NAME

對於人物傳記,現有編者認為日語人名若尚未有正式譯名,則應以羅馬字代替原名。

然而,光這點就與模板{{NotChineseTitle}}互相牴觸了:羅馬字並非原文,也就是羅馬字不等於日語。

再者,舉幾個例子:

  • 椋木 ななつ(Mukunoki Nanatsu)
  • 吉辺 あくろ(Yoshibe Akuro)
  • 卯花 つかさ(Unohana Tsukasa)
請問何者一眼就能容易辨識是人名?答案可能不盡然,但在下認為使用羅馬字很可能會誤認為其他人或事或物(雜誌、網站或產品的可能性極大)。

方針矛盾的地方是,Wikipedia:命名常规#使用中文已有規定若無中文譯名,則應使用常用原名,但是還有編者堅持非原名的羅馬字。

小的祈求各位大大能關注此項議題。--MeritTim 2019年5月10日 (五) 09:24 (UTC)[回复]

  • 「使用常用名稱」中有指「條目命名應該儘量使用可靠來源中人、物或事項的最常見的名稱」。如果羅馬字並非主體在可靠來源中出現得最多的名稱,羅馬字就不應該被使用,沒有中文譯名的情況下應該使用日文原文或按日文原文暫作一譯,以後者比較好(根據「使用中文」)。名稱的可供查證性也能夠容易讓社羣判斷名稱是否「易於識別」。Σανμοσα以有涯隨無涯,殆已! 2019年5月10日 (五) 09:31 (UTC)[回复]
    • 當然,如果羅馬字是主體在可靠來源中出現得最多的名稱,那時就可以使用羅馬字,因為其可供查證性已使之「易於識別」。Σανμοσα以有涯隨無涯,殆已! 2019年5月10日 (五) 09:35 (UTC)[回复]
      • @Sanmosa就如閣下說的是,由於目前「易於識別」的名稱為日語原名,而該編者執意移動至「較不易辨識」的羅馬字,實在不知如何面對。另外,在下添加了新的內容,閣下可以做為參考。--MeritTim 2019年5月10日 (五) 09:41 (UTC)[回复]

我提出这个问题主要源自Talk:カツヲ中关于条目重命名的讨论。考虑到此问题并非个例,所以也在这里提出,希望各位帮助讨论。

一般而言,这个问题是指当条目主题人物(也可能是别的专有名词)的名称包含日文假名且没有正式或常见的中文译名时,是否应当依据方针将条目命名为对应的罗马字。

维基百科:命名常规中可以作为依据的内容,我觉得主要有以下几点:

“使用中文:在中文维基百科,条目的标题通常是中文标题;惟若原文名称比中文翻译的名称在中文中更加常用,或如果不存在中文翻译的名称,则应使用原文名称。”
“使用常用名称:条目命名应该尽量使用可靠来源中人、物或事项的最常见的名称。”
“使用外文命名时的专门要求:一般而言,条目名称应被翻译成中文。只有当外文词在中文可靠来源中被广泛使用时,或缺乏中文可靠来源且确实难以翻译时,才应使用外文作为条目名称。如果一个条目需要使用英文等其他语言命名时,在创建页面的时候,需要遵守下面的规则。”
“罗马化:条目名称应尽可能使用拉丁字母,对于非拉丁字母的语言应使用拉丁字母转写……罗马化时,应使用在社群获取共识的方案;如果社群未对相应语言罗马化方案达成共识,应采用该语言的标准罗马化方案……如有充足的中文来源描述条目主题,应使用这些来源中的写法;即使这种写法不匹配上述关于罗马化的规定,也应采用。”

那么依据方针,我的个人意见是,遇到上面描述的问题,如果不易翻译成中文,则通常可以用原文命名,但同时应当将日文名中的假名转写为罗马字,作为条目名。就我个人熟悉的情况来说,漫画家NamoriKaduhokakiflyHato Popoko、配音员桃河Rika等条目都采用了这种命名方式。“分类:日本漫画家”中凡涉及到类似情况的,大多数也都是这样命名的。此外经我部分查询,在分类:日本艺人的诸多子分类中也可以找到许多以这种方式命名的条目。这些先例的存在,说明中文维基对解决此类问题,应当是有共识的。

但是具体到个别条目,也有不同意见。比如我前面提到的Talk:カツヲ,由于和一位编辑者意见不同,我才到这里提问求助。这位编辑者认为漫画家カツヲ(Katsuwo)若干部作品的中文版,其出版社(台湾角川和尖端)或部分书店使用的作者名都是原文的片假名,因此不同意将条目重新命名为罗马字。这位编辑者新建条目タチ(Tachi)的命名应该也是基于类似理由。而我认为仅根据出版社和部分书店,不应认定“カツヲ”能够符合命名方针中“最常见的名称”和“有充足的中文来源”等要求;而且我也指出前述出版社中的台湾角川在版权信息中使用的是作者名的罗马字,讨论中也有另一位编辑者提供了另一些书店使用作者名罗马字的证据。此外,以我前面提到的Namori、Kaduho、kakifly为例,他们作品中文版的出版社(东立、青文、尖端)也和Katsuwo和Tachi的情况类似,并未将作者名翻译成中文且保留了原名中的假名,但相关条目的创建者和编辑者仍然采用罗马字命名,我认为这3个例子,以及前一段中提到的许多类似条目命名,都可以成为カツヲタチ命名的参考对象。--Lucho留言2019年5月9日 (四) 20:59 (UTC)[回复]



整合一下:

  • 人物傳記的標題應使用常用名稱作為標題,倘若標題並非中文,則使用羅馬字重定向至條目,而非將條目移動至羅馬字標題。
  • 命名常規的使用順序是否應以原則為優先,而其延伸例外是否不得凌駕於原則之上,將在下方繼續討論。

此並非最終結果,上述仍會更新。--MeritTim 2019年5月10日 (五) 16:19 (UTC)[回复]

  • 我也明确反对Sanmosa对当年用户的发言做出不合适的过度理解。当年这句“怪怪的……”没有其他解释,原本不知是在评论哪一条内容,但由于是紧跟在“只要有保留日文原名的重定向,应该都没什么大问题”这一句评论之后,而这一句评论中的实质内容只有“保留日文原名的重定向”,因此与这一句有关的可能性最大,很难认定“怪怪的……”是在评论别的内容。对比发言时间和存档时间,也可以知道并无确凿理由认为“該討論在未達成共識以前已被強行存檔”。您既然认为“现在可以推翻”,那何必要在没有充分依据的情况下否认当年明确达成的共识?另外请您解释什么是“修訂後發生了重大變化”,以及为什么“原有的共識很可能不適用”。----Lucho留言2019年5月12日 (日) 09:11 (UTC)[回复]
  • 过去的共识当然可以推翻,但麻烦各位努力达成共识。以タチ条目为例,我认为条目名称不可以是片假名,需要改成Tachi (漫画家)之类的样子。而所谓常用名称(タチ)可以重定向到Tachi (漫画家),而且我明确不认同タチ是常用名称,请题主给出可靠中文来源证明片假名名字是中文里的常用名称。这是中文维基百科,就连注音符号都是地方中心的字符,不建议放在条目名称里,更何况日文假名了。 --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨᡩᠠᠨMandan 2019年5月13日 (一) 02:49 (UTC)[回复]
    • 我认为过去并未存在共识,但共识的需要还是存在的。我认为如果大家同意的话,可以確立罗马化的优先性(例如:只有沒中文名稱而絕大多數可靠中文来源使用假名時方可使用假名,否則必須罗马化)。Σανμοσα以有涯隨無涯,殆已! 2019年5月13日 (一) 06:26 (UTC)[回复]
      • 我同意现在应当做的是取得一个当前的共识。我也同意两位发言中的“条目名称不可以是片假名”,没有“可靠中文来源”证明タチ是“中文里的常用名称”,“確立罗马化的优先性”等观点。--Lucho留言2019年5月13日 (一) 12:12 (UTC)[回复]
  • 我的見解是雖然不能完全否定使用假名作為標題的可能性,例如くぁwせdrftgyふじこlpへのへのもへじ等等,但是這只是屬於相當局部的例子。那是因為如果生硬地換成羅馬字的話,原來的意思會變得難以理解,在中文語境中反而變成不常用。就日本人名來說,中文文獻多有直接複製貼上陋習,尤其是並非所有媒體均精通日語,導致假名類往往直接搬過來的情況更加明顯,因此假名名稱散見各種媒體並不就一定等於常用名稱。就我個人來說,我同樣支持在沒有通譯的情況下,比較建議使用羅馬字作為標題。謝謝。—AT 2019年5月14日 (二) 07:40 (UTC)[回复]
    • 除了AT君所提的少數特例外,我也認為羅馬拼音化是條目標題的唯一選擇,不管媒體或網站有沒有常常直接複製貼上這些假名字,對於不懂日文的人這些字就是亂碼,連辨識都有困難更不用說要利用他們在維基百科內進行整理。這原則不應只侷限於日文,而是通用所有語言。所以如果那些懂日文的用戶無法理解為何中文維基要這麼嚴格的話,請想想如果今天條目是韓文字母、是西里爾字母或甚至是阿拉伯文或樊文時,您還可以輕鬆看待嗎?--泅水大象訐譙☎ 2019年5月18日 (六) 04:23 (UTC)[回复]
    • 英文維基都沒有可能用中文命名條目吧!為什麼要在中文維基用日文?此例一開,正如大象所言,泰文、俄文、韓文都可以用來命名條目了。日文愛好者何不直接到日文維基進行編輯?—以上未簽名的留言由14.0.230.179對話貢獻)加入。
    • 支持AT的观点。任何简要的主张当然都非常容易有例外,如同AT举的例子,如果改为罗马字会明显影响传达,则应当保留假名写法。 --ᡠᠵᡠᡳUjui ᡠᠵᡠUju ᠮᠠᠨ᠋ᡩ᠋ᠠᠨMandan 2019年5月21日 (二) 03:09 (UTC)[回复]
  • 根據命名常規首段:「如果條目所屬的專門領域存在具體命名規定,應遵照該規定執行,而不再按照命名慣例的要求確定名稱;但這些條目仍需遵守技術要求一節的規定。」所以大家要不要為此立下專屬規則以便跟隨?Σανμοσα以有涯隨無涯,殆已! 2019年5月18日 (六) 15:32 (UTC)[回复]
  • 維基百科負有知識普及的使命,如果用其他語言,大多數用戶看不懂,而且打字也打不出來。「這領域裡大部份的人都這樣用」不足以當作保留原文的理由,否則幾乎所有的學術名詞和比較不有名的外國人名都要改成英文了。就算是在中文地區的學術界,大家也都講 Dobzhansky、Tajima's D 和 inclusive fitness,而不是費奧多西·多布然斯基田島D檢驗整體適應度。這裡是中文維基,能翻中文的都應該用中文,連羅馬字都應該盡量避免,只有像 AKB48hideiPhone 這種因為縮寫、官方立場、或已經成為外來語的,才可以保留羅馬字。タチ要翻「塔及」還是「達」還是「夕千」我不管,交給懂日文翻譯的人決定。 --Yel D'ohan留言2019年5月22日 (三) 19:26 (UTC)[回复]

本討論已關閉,請勿修改。如有任何意見,請在合適的討論頁提出,而非再次編輯本討論。

相關羅馬化議題就此打住,在下已將含有爭議的頁面標題羅馬化了(在下若再不下台到時會很慘),現在該討論的是導言是以羅馬化後的標題做為開頭,還是原文?個人傾向原文,起碼標題羅馬化不至於是某人所述之亂碼,這樣使用原文也能尊重被提及的當事者。

目前僅剩卯花Tsukasa含有中文化爭議,因爭議發起者提議將標題改為卯花司,但Special: MobileDiff/54415035顯示當事人提出的來源並非可靠來源。

以上,謝謝。MeritTim 2019年5月24日 (五) 15:08 (UTC)[回复]

又莫名其妙吵起來的文字格式#颜色及内联图像問題

難道不能在Wikipedia:格式手冊/文字格式#颜色及内联图像加上案例嗎?說真的。雖然有討論過建議修改文字格式#颜色及内联图像,但我覺得仍有很多人不能理解(沒錯,就是有人看不懂),雖然我被人說過「方針不是操作指南,亦不是巡查手冊」,但格式手冊沒指南,又寫的很朦朧,還是說這些東西可以寫在Help:列表或者是Help:表格(他們算指南嗎?)。 --船到橋頭自然捲*留言*Violeta 2019年5月16日 (四) 15:35 (UTC)[回复]

能否具體點?是哪句含糊?還是整段?會否有事例?--J.Wong 2019年5月18日 (六) 14:44 (UTC)[回复]
@Milkypine?—— Eric Liu 坐等萬次編輯留言留名學生會 2019年5月26日 (日) 15:21 (UTC)[回复]
一望WP:FLC而知。--Rowingbohe♬~Taichow·Sign 2019年5月26日 (日) 15:26 (UTC)[回复]
我都忘了我有發過這鬼東西...,反正自從FLC之後都沒有甚麼大規模吵架,就當作沒有這回事好了。 --船到*橋頭*自然捲 2019年5月26日 (日) 15:31 (UTC)[回复]

建議完全整合合併請求頁面存廢討論

雖然合併請求頁面存廢討論已經在1月合併,但是在實務操作上,如果要在AFD提出合併請求,預設的做法是刪除條目,不可以用其他沒那麼帶刺的方法申請合併。最近提出合併請求的時候,首先是機器人不認受{{Mergeto}}的地位,認為{{VFD}}才是有效的提刪模板,然後其他用戶也以「沒有懸掛『有效的提刪模板』」為由,否決我的合併請求。雖然我已經表示反對否決,不過估計以這個情況來看,保留的機會率非常高。

我在這裏就是看,能不能夠做得好一點。有時候僅僅是內容整合,本來的條目不至於刪除,而是可以保留作重定向。看看我們能不能:

  1. 在頁面存廢討論承認{{Mergeto}}的地位,或者
  2. 把{{Mergeto}}的內容轉到{{VFD}}。

--春卷柯南編輯數突破二萬 ( ·刻石留名 ) 2019年4月19日 (五) 08:29 (UTC)[回复]

編輯點

  • @Wong128hk:那現在要怎麼處理這個問題?稍後再議?User:春卷柯南User:Willy1018User:悔晚斋User:CohafUser:94rain-- Sunny00217 - 2019年4月28日 (日) 12:22 (UTC)[回复]
  • 打算正式動議,推翻二○一九年二月討論,重啟Wikipedia:合并请求。原打算明日提案,明日才夠七日。--J.Wong 2019年4月28日 (日) 13:24 (UTC)[回复]
    • 基於社群慣性(Inertia),我不認為再度分立是好事。社群由始至終根本不認為合併請求能做些甚麼,提出合併全是交到AFD,合一的目的並不是為了增加效率,而是為了迎合慣性。Σανμοσα y=0 regardless the value of x 2019年5月1日 (三) 10:28 (UTC)[回复]
      • 但這個慣性有明顯問題,為什麼不是予以糾正,反而去迎合這個慣性呢?不太合邏輯。所謂「社群慣性」不能解釋「不認為再度分立是好事」,請提供更多理據支持該說法。--J.Wong 2019年5月6日 (一) 13:12 (UTC)[回复]
        • 既是社羣慣性,則為沉默共識,所以除非有充足、廣泛討論認同應該再度分立,否則不迎合社羣慣性基本上就和違反共識畫上了等號。再者,社羣也因為兩者的合併而為結案提供了更多選擇(例如「ma」參數),社羣慣性所衍生的額外問題已正逐步消除。Σανμοσα五四运动百週年 2019年5月7日 (二) 09:18 (UTC)[回复]
        • 當初合併亦沒有充分討論,上面問題也沒有思慮過,討論過。現在就在討論這件事呀,請為繼續合併提供足夠理據支持。何況什麼是慣性呢?過往社群並不會將什麼合併請求都拋到存廢討論,現在反而是被迫改變習慣,將所有合併請求都拋到存廢討論。「ma」(允許合併)將整件事弄得更為複雜,什麼是允許合併?什麼狀況下不用合併,而要用允許合併?奇怪。「社羣慣性所衍生的額外問題已正逐步消除」,請為此論述提供數據支持,例如︰衍生了什麼問題,當初合併前是什麼狀況(基線),合併後到現在又是什麼狀況,做一個詳細比較。--J.Wong 2019年5月18日 (六) 15:02 (UTC)[回复]
          • Template talk:TalkendH#Template:TalkendH新增「允許合併」參數,“ma”的定義是管理員委托其他用戶代為手動合并,因為部分管理員在處理已經達成合併共識的AFD時不(多數情況是「未能」)手動合併相關頁面。如果社群的慣性是將合併請求提交到PM的話,我當時就不會創造{{delpmh}}了,但是創造了{{delpmh}}還是收效甚微。現在的情況是多了一些合并提案供社群討論,但有機會頁面適宜合并,但沒有人參與討論(當時的一種做法是“暫時保留:請自行合併”,但只是少數做法),加入了“ma”就可以稍微加快部分的合併請求程序。Σανμοσα以有涯隨無涯,殆已! 2019年5月18日 (六) 15:22 (UTC)[回复]
            • 首先,翻查「合併請求」一月份存檔,還是有用戶向該頁提交合併請求,所以請分清楚究竟社群慣性行為是什麼。
            • 其次,要創建{{delpmh}}並等於社群想將全部合併請求拋到存廢討論,也可以是個別用戶誤會操作流程。
            • 其三,此項討論其實正正反映出存廢討論無力應對/不想處理大部分由刪除請求轉化而成的合併請求,所以才會出現「暫時保留︰請自行合併」,那還將其餘本身與刪除不相關的合併請求往存廢討論推,是什麼玩法?這是警兆呀,沒留意到嗎?由始至終,流程都沒有加快呀。頁面是沒人合併,也是沒人合併,別自欺欺人,好不?要是想有人去裁決是否適合合併,合併請求放到「合併請求」一樣也可以有人去裁決,裁決者不一定要是管理員。
            • 請搞清楚問題所在,再行施藥,別藥石亂投。以上。--J.Wong 2019年5月19日 (日) 00:45 (UTC)[回复]
  • 发表些个人意见。我是比较支持合并请求并入存废讨论的(或单立一处,但未见必要),目前合并请求无人处理,就个人想法来说,是因为合并请求的处理流程不清晰,不知道何时、可由谁处理。比如说,有时看到新进提交或已提交一阵子的合并请求无人发表意见/执行合并,我不知道是否能直接完成合并和关闭讨论,希望能有操作流程/指引讲清楚。具体而言:提报多久后可着手合并(如3天或7天且无异议)。合并人能否结案讨论(良性环境下不建议)。有异议或讨论中能否尝试合并(可能唐突,也可能展示、协作出合并成果。后者与问题1有关联)。如何、何时请求管理员协助(如一个标识模板和/或维护分类),移动、合并历史是否要公示等待(因为难撤销)。以及应鼓励发表支持/反对意见。等等。--YFdyh000留言2019年5月19日 (日) 06:16 (UTC)[回复]
    • 集中處理合併請求的確會比較好,但不是集中到存廢討論。存廢討論應該主要用於處理刪除決定及申請,而合併選項只是為了履行「刪除乃最後手段」原則而存在,即是如果一開始就不認為需要刪除就不應該提交到存廢討論。這點需要重申。所以合併請求由始至終只應該有一處,就是「合併請求」。
    • 合併流程的確有欠明確,可以於此討論一併處理。
    • 參考英文維基,有將合併請求分為三類︰一、明顯需要及合適,可預期沒人會異議;二、需要就是否合併及如何合併於條目討論頁與其他編者展開討論;三、有爭議或難以合併,故而需要其他第三方編者協助決定是否合併。
    • 第一類可以直接進行。第二類也只是掛模板就完事。第三類才需要提交到「合併請求」。第二類,申請人應該要有意願去合併條目。
    • 參考英文維基上列標準,第一類,個人認為可以同樣毋須提交申請以至懸掛模板。第二類,懸掛模板,列於「合併請求」七日,如無異議,申請人可以執行。執行後,如遇有異議,歸為第三類,再議。第三類,討論以解決爭議及困難以及達成共識為本,建議討論最長維持八週。如八週仍未能達成共識,則應考慮暫且擱置。時機成熟時再重啟討論。如有困難,可同時提交到互助客棧條目探討區。
    • 以上。--J.Wong 2019年5月19日 (日) 08:33 (UTC)[回复]
      • 1及2类無異议(2类方面,其實是否設立一個請求頁面並沒有關係,因為可以使用分類追蹤)。3类方面,如果最終發現被合併的內容原來應該被刪除,而刪除理由並非關注度/小小作品,又如何?Σανμοσα以有涯隨無涯,殆已! 2019年5月19日 (日) 09:19 (UTC)[回复]
        • 那不如閣下寫一下為什麼要併兼。
        • 這要搞清楚呀,所謂刪除是什麼意思,是單純從頁面移走相關內容,還是要整頁刪去。除關注度以外,基本上是否需要刪去,應該很容易分辨。要刪除,就去存廢討論;要合併,就去合併請求,很困難麼?而且閣下資料也太少,是為什麼會「最終才發現被合併內容原來應該被刪除」……--J.Wong 2019年5月19日 (日) 12:53 (UTC)[回复]
          • 於目標頁面而言是刪除相關內容。「最終才發現被合併內容原來應該被刪除」的情況通常是侵權和廣告(尤其是前者);AFD參與者普遍上比較眼利,能夠分辨到這些問題。至於可供查證性、中立性等等問題,那些內容可以刪走,也可以掛模板提示。Σανμοσα以有涯隨無涯,殆已! 2019年5月20日 (一) 10:20 (UTC)[回复]
    • 基本上,这些年来,我对于合并的处理大致也是三种情况(类似上面说的英文版情况),我觉得不少人也应该和我的状况类似:第一种是明显无异议的合并,一般都是同一主题不同名称,比如中国历史中国的历史合并,看到了自己就动手解决了(在有能力的前提下);第二种就是挂模板,可以再分两种子类,一种是自己感觉应该是要合并的,但不是非常确定,挂上模板后可以在讨论页留言(多半的情况是不确定应该是A合并到B,还是B合并到A),另一种是第一种情况的延伸,明显无异议需要合并,但是自己没时间和精力去处理,或者对该领域不熟悉,不知道如何下手去合并具体的内容,那就先挂上模板,让其他有能力合并的人看到后去合并。第三种相当于英文版第三类情况,我一般都是直接提交到存废讨论,一般都是A要合并到B,或者A的部分内容需要合并到B,然后删除A。这样实作的主要原因是,通过TW我只会两种合并操作。要么挂上合并模板,然后讨论页留言,要么提删。我不知道如何用TW提交到合并请求页面?我认为合并请求还是非常需要的,但如何设计流程让其发挥更大作用可能需要重新思考。--百無一用是書生 () 2019年5月20日 (一) 02:45 (UTC)[回复]
    • 另外,不要忘了还有条目拆分这一类,这是合并的反面,这种又如何处理?--百無一用是書生 () 2019年5月20日 (一) 02:48 (UTC)[回复]
  • 或許這樣:不如弄個暫行辦法,在{{vfd}}加入以下參數:「merge|合併|合并=Vfd-merge」,並把Draft:Template:Vfd-merge移動至Template命名空間,然後合併請求是否再分立則另議?至於針對上面提及的分拆的問題,我認為可以照板煮碗讓AFD處理分拆請求,並且也照板煮碗設置一個Template,也當作暫行辦法,分立也另議?Σανμοσα以有涯隨無涯,殆已! 2019年5月22日 (三) 08:53 (UTC)[回复]
    • 當然,在現時的情況下,如果能夠在AFD頁面中提示編者只有在未能自行合併或合併有爭議的情況下才提交合併請求至AFD,會比較好。Σανμοσα以有涯隨無涯,殆已! 2019年5月22日 (三) 08:53 (UTC)[回复]
    • @Wong128hkShizhao春卷柯南Hat600@Willy1018悔晚斋Cohaf94rainSunny00217Σανμοσα以有涯隨無涯,殆已! 2019年5月22日 (三) 08:57 (UTC)[回复]
    • 《刪除方針》︰「如果一個頁面的內容本質上沒有導致刪除的問題,而標題不合乎要求(例如,名稱不符命名常規或其他專題指引的要求,但內容合適的條目;適合一個命名空間的內容被錯誤地放在了另一個命名空間中的情形),可以直接將它移動到合適的標題下,或是提出移動請求(對於無移動權限或有爭議的情形),而不需要將它提交到存廢討論」然後,Draft:Template:Vfd-merge︰「根據維基百科刪除方針,此頁面已被提出請求併入Template:Vfd。」當中似乎有所矛盾。《刪除方針》其實很明確,存廢討論不是處理合併請求之地。個人不認為可以暫行之道。請恪守《刪除方針》,將「合併請求」還原。--J.Wong 2019年5月23日 (四) 09:34 (UTC)[回复]
      • 如果社群其他人大部分都認同應該可以使用暫行辦法的話,我認為這樣可以凌駕於方針。還有,社群對於是否重開合併請求似乎沒大興趣,我不認為就討論在現階段能夠達成甚麼共識,現在似乎還不是重開的時候,WP:IAR可以適用了。Draft template字句問題已修正。Σανμοσα 2019年5月23日 (四) 10:11 (UTC)[回复]
      • 個人同樣不認為在點出問題後有其他人認為此乃可暫行辦法。不應該以此為由凌駕既定方針。而此舉亦無為本站帶來任何好處,是故亦未見有任何理由可援引《規則忽略方針》。修改模板並無真正根治問題之所有。個人由始至終都未明白是為何故而要將頁面強行合併。分拆歷史遠長於合併,是故支持合併理由準備足夠、充分理據。請勿一直迴避問題之所在,提出足夠理據支持此做法。正如閣下上面回覆,此合併並非為效率。然後,又發現此合併並無法改善積壓問題,只是將積壓由一處掃往另一處。為習慣故?又發現其實過往社群並不會將全部合併請求拋到存廢討論。所以到頭來,究竟此合併為何原故?為方便?那請問有沒有試過要求技術帝幫忙支援合併請求?又有沒有試過改善合併流程?--J.Wong 2019年5月24日 (五) 03:47 (UTC)[回复]
        • 改善合併流程?基本上,此前有關合併請求的討論的參與率都不大(除了併入AFD那次),可見社群對於改善這方面的流程已經抱持負面態度(我曾經弄過存廢討論轉介合併請求的關閉模板,但最終只用了一會就不用了,也是出於這個理由)。還有,Xiplus版Twinkle似乎只是在近期才開始在老手間熱門,而且中文維基百科的Twinkle正式版本是Jimmy Xu版本,即使Xiplus版Twinkle支援了,也不見得效果有多大。Σανμοσα 2019年5月24日 (五) 10:53 (UTC)[回复]

关于DYK“基本推荐资格”,“重写后长度不得缩短”这一条件的疑问

以上。Σανμοσα 2019年5月23日 (四) 10:19 (UTC)[回复]

  • @Sanmosa可以直接公示吧。—— Eric Liu 坐等萬次編輯留言留名學生會 2019年5月25日 (六) 10:51 (UTC)[回复]
  • 如果在本月底通过的话,可以考虑在6月1日正式实施。--№.N留言2019年5月26日 (日) 08:37 (UTC)[回复]
  • 由於此提案并沒有受到任何明顯的反對意見,基於時限特殊性問題,現公示提案至2019年5月31日 12:00 (UTC),届時如無合理異議,新規則將於2019年6月1日 00:00 (UTC)實施。Σανμοσα 2019年5月26日 (日) 10:26 (UTC)[回复]
  • (-)反对修改。根据之前的强制要求是增加的内容必须达到原文的2/3,即原条目3000字节,修改后的条目必须达到5000字节,这个是为了防止通过单纯洗牌、增加来源格式就能实现的情况。很多年前有过讨论(但我找不到,但仍然可以试验一下),即通过来修改来源通常只能增加2000字节左右。其实对大多数编辑而言,增加2000字节并非难事,除非真的是没有能力去编写,或者限于条目本身很难写到DYK的要求(这回答了为何重写诚然无法本质促使文字增加,而此类重写也无法符合DYK标准)。这些字数要求已经综合考虑了这些因素,单纯使用“撤销字数要求”而强调“主观判断”,即会导致有用户通过凌驾社群、排除异己、加上没有任何客观字数要求,从而实现霸占的目的。🌜山西特产批发零售™️🌽🌶️🍎🍠🐓🐐留言2019年5月28日 (二) 06:47 (UTC)[回复]
    • 可是去除一些愛好者內容、不符格式的文字、區塊染色也是條目優化。 --船到*橋頭*自然捲 2019年5月28日 (二) 06:57 (UTC)[回复]
    • @Walter Grassroot首先,這裏討論的是重寫規則,對於非重寫的擴充的規則並沒有影響,請勿混同。其次,重寫規則的要求是大幅改善,我不認為單純修改來源格式或增加來源可以算是「大幅改善」,而且以上意見明顯忽略了諸如剷除愛好者內容等必然會導致字數減少的情況(這樣很明顯是讓條目變得煥然一新的做法,能擔當得起新條目的「新」字,反正現時提出修例的原因是規則有錯,新規則符合DYK本意就好)。再者,新規則設有原文保留篇幅限制(1/3),純粹調換原文次序也並不符合新規則,而我也不認為最多只可保留1/3原文這個限制本身有任何主觀成分。綜上,我認為WG並未有完全清楚閱讀整個討論,所以我也不會視上述反對意見為合理反對。Σανμοσα 2019年5月28日 (二) 09:21 (UTC)[回复]
    • (~)補充:現行重寫規則只要求重寫後長度長於重寫前長度,並不跟隨擴充規則的字數最低要求限制(這就是我說WG把規則混同之處)。Σανμοσα 2019年5月28日 (二) 09:42 (UTC)[回复]
    • 順帶一提,WG也意外忽略了部分規則:原條目3000位元組,修改後的條目必須達到6000(而非5000)位元組,因為非重寫的擴充需要同時符合至少3000位元組擴充和至少有原文2/3擴充(=實際計算上較高字數要求者為準),當時武漢軍山長江大橋若非WG也幫忙擴充了些許(以符合至少3000位元組擴充),否則條目就不合要求而不能通過DYK了。Σανμοσα 2019年5月28日 (二) 09:49 (UTC)[回复]
  • (-)反对:DYK是擴充和改善條目並重,重寫如果縮短了,你最多只能叫改善條目,不能叫擴充條目,擴充就是一定要比原文長,比原文短就不叫擴充。重寫規則為什麼要比原文長,明顯是因為要守護DYK的擴充精神。如果原文滿是不適合的內容,那麼應該提出討論刪除有關內容,有共識後由其它人刪除,之後才自己重寫,而不是不經過討論,自己先斬後奏把原文內容刪除後直接重寫。--Opky9407留言2019年5月30日 (四) 13:02 (UTC)[回复]
    • 我不認為DYK有所謂擴充精神存在,DYK本質上是為新條目而設的,條目的底蘊只要足夠新即可,我未見DYK和擴充有何直接聯繫。Σανμοσα 2019年5月30日 (四) 14:13 (UTC)[回复]
      • DYK一直都是著重擴充擴寫,初期的規則早就已經包含擴充的精神,一直留存到現在,這一點不能否定。--Opky9407留言2019年5月30日 (四) 18:00 (UTC)[回复]
      • 楼上对于Opky9407反对意见的后半句如何解释呢?后半句的意思是说想先删除内容后将删除后内容作为DYK提名的修订前版本。虽然两个反对都有不合理之处,但是其存在本身对于公示期限与新规生效日期也会产生一点点影响,还请楼上注意视情况再次评估是否需要延长公示期限。--№.N留言2019年5月30日 (四) 14:57 (UTC)[回复]
        • @Liu116對於Opky9407後半句的解釋,如果有方針指引支持移除動作,由於方針指引屬於大範圍共識,按理任何人都可以直接刪除相關内容,未見有必要提出討論是否刪除(參考例子見Wikipedia talk:香港維基人佈告板#分段中管理員AT的留言:“掛維護模板變相只是一種掩耳盜鈴的做法,根本的問題完全沒有得到解決。當然如果有用戶願意出手整理,那當然無任歡迎。可是在不存在的情況下,就應該考慮直接清除。換個角度,這些內容大多已經長期存在於中維,一直缺人整理,難得有人願意出手清除,卻反而受到刁難,站在維護的角度來看,我是覺得非常奇怪。反之,清除這些內容其實是刻不容緩,讓這些內容長期存在於維基,對維基來說反而造成傷害”,裏頭的“這些内容”對應的正是不適合的內容)。由於早已經有合理反駁“提出討論刪除有關內容,有共識後由其它人刪除,之後才自己重寫”論的存在,我不考慮再做任何解釋。Σανμοσα 2019年5月30日 (四) 15:16 (UTC)[回复]
        • 對於WG的意見,我回應時已經ping了他,他沒回應的話我就當成我有合理解釋反駁了。Σανμοσα 2019年5月30日 (四) 15:24 (UTC)[回复]
          • 只由一個人判斷原文內容有沒有違反方針,絕對不適當,有方針支持刪除是一件事,但在刪除前有沒有正確判斷方針是一件事,你提出的理據根本沒有對應反駁到,WG說的主觀判斷的問題我十分認同,很容易造成一些用戶為了重寫而過份誇大方針,而肆意刪除本來沒有違反方針的內容。--Opky9407留言2019年5月30日 (四) 18:00 (UTC)[回复]
            • 社羣在參與DYKC時有責任查閱修改前和修改後的版本如何,如果他們認為修改前的版本並非不合方針指引,那他們可以投 不合要求票,反之則可投(+)支持票,有4票淨支持則通過;DYKC可不是單純有人提名就能通過的。2位反對者很明顯無視了這一點。還有,我也認為AT將能有效駁斥2位反對者。Σανμοσα 2019年5月31日 (五) 01:58 (UTC)[回复]
  • 雖然我是傾向支持,但現在的情況顯然需要延長討論,敝人不會在6月份完結前執行有關重寫之修訂。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年5月31日 (五) 00:37 (UTC)[回复]
  • 继续(-)反对一下。我没有立即回应,不等于我支持或者同意阁下的看法,请不要脑补;恰恰相反,我觉得继续陷入这种低价值讨论,无论是你还是我,都是在浪费彼此时间。
    • 通过一项议案,最有效的方法就是把客栈弄乱,让这里继续成为沆瀣之地、藏污纳垢之所。继而在一项大的讨论中,采用政治分肥的方式,夹带着把一些议案以“无明显反对意见”,实现通过。这是目前中文维基百科中最有效的议案通过方式。
    • 其次才是阁下采用的否定之否定,即把反对者以“了解不足、经验不足、参与不足、贡献不足”等理由,否定反对的资格,强行把议案通过。这种概率相对低,但也可以采取。只是吃相会很难看,条目存废领域因为关注较低所以倒是常见,客栈通常难,但阁下可以尝试闯关。
    • 第三回到议题,我认为目前DYK的条目重写问题是在重写后应大幅扩容,即无论你用没有用之前的原文,至少要多出二分之一甚至一倍、两倍的内容,这样才能实现形式和实质的扩充与重写。对原文的使用多少、原文的准确内容有多少,涉及到对条目之前编辑贡献者的主观评估(而且既然是要大幅重写,大概率是有批评的成分)。以前我们条目撰写,都是商量着来的,如果有朋友要大幅重写我的条目,会私下找我,我也会把之前我查到的资料、遇到的一些编辑问题一并交给朋友,偶然也回头补充补充。只是看到目前很多人写,恨不得扒高踩低,写完了还在站外骂上原编辑几天几夜的(甚至和原编辑仅仅有过交情的编辑也容易被牵连躺枪)……虽然我无心阻止客栈互煮的文化扩大化,但是目前重写标准要因为某人某事而降低,我无法赞同。另外说一下,我后续的确无心参与客栈互煮,所以ping不ping我没有回,不代表我的意见更改🌜山西特产批发零售™️🌽🌶️🍎🍠🐓🐐留言2019年5月31日 (五) 01:54 (UTC)[回复]
  • (+)支持,重寫後位元組少於以前是很有可能的。例如,本身條目充斥大量雜碎資訊的情況下,重寫後必然地這些資訊會因為經過整頓或清除,而導致位元組可能少於以前,所以我認為重寫後就算位元組變少,選DYK也是沒有問題。如果覺得重寫得不妥當,還可以投反對票,然而持續實行現機制卻是等於叫別人不要去改善條目,顯然地為了避開這個問題,更多人會選擇直接創建新條目或擴充一些沒有問題的條目,從而讓有問題的條目繼續陷入沒人整理的狀態。—AT 2019年5月31日 (五) 04:44 (UTC)[回复]

提議建立非中文重定向快速刪除標準

^已編輯標題以描述討論內容。 Vakrieger♀留言2019年5月30日 (四) 06:09 (UTC)[回复]

我希望社羣能發表一下對於是否支持快速刪除違反WP:RDRNC的重定向的意見。Σανμοσα以有涯隨無涯,殆已! 2019年5月22日 (三) 09:12 (UTC)[回复]

以上,附通過後須加入至模块:Template:Delete/data模組碼Σανμοσα 2019年5月25日 (六) 04:01 (UTC)[回复]

  • 直接加到沙盒了:Special:Diff/54549482-- Sunny00217 - 2019年5月25日 (六) 12:17 (UTC)[回复]
  • (!)意見,那其實第一、二項都會有爭議。第一項:提刪者可能不熟悉某範疇的學術名稱,因為未必容易搜查得到,所以應該透過存廢討論讓人探查某學術名稱的存在性。第二項:與第五項的問題類似——何謂「知名」?這一樣可能會有潛在爭論。其他的我稍後再評估。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年5月25日 (六) 20:11 (UTC)[回复]
    • @Cdip150RDRNC第一項其實就是允許外文專門用語及動植物的學名重定向,如果看上去是生僻字的話,用戶理當查一查有沒有字典解釋,如果沒有字典解釋,但卻有一大堆學術文獻提及的話,就符合RDRNC第一項;有字典解釋就不符合,可以R8;沒有字典解釋,也沒有學術文獻提及的話,就很可能是虛構或廣告,可以G3或G11。RDRNC第二項,你似乎漏了“國際”,你能舉一些例子針對“國際知名”再説明一下爭論之處?。Σανμοσα 2019年5月26日 (日) 10:06 (UTC)[回复]
      • 第一項:別想得那麼美好,就算完全按照了您的做法,始終提刪的人未必是熟知該範疇的,他的提刪很可能引起比他更熟悉的人提出更有效的反證(要知道學術文獻十居其九都沒有在線版,就算有在線版的也很多都要付錢看),而且要以一本怎麼樣的字典來斷定去留本身都已可圈可點(就算是牛津字典都有分階的,收錄的範圍也有不同;我看的字典沒有,但他說他看的字典有,已經可以論個翻天了),所以我覺得錯誤速刪的風險還是很高,還是交存廢討論比較穩陣,無論是R8、G3還是G11都不適宜。第二項:有沒有漏並不重要,何謂「知名」?何謂「國際知名」?都會產生爭論。舉個例:Grand Prix Macau是否為國際知名的賽事?外界經常說她是享負盛名,但實際上根據最近一次的對澳門賽車的認知調查,結果非常令人捂臉。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年5月26日 (日) 16:49 (UTC)[回复]
        • @Cdip150第一項方面,只要有任何一本字典有那個字就不可以建立,現時社群做法如此。還有,第二項只限企业与建築適用。。。Σανμοσα 2019年5月27日 (一) 05:46 (UTC)[回复]
          • 第一項:即使如此,當某人說在字典找到,顯然就需要透過存廢討論提供證明讓人核實有關說法,這點無可避免要經過討論,而且如果某人是以一本稀有的字典來提刪某學術重定向的話,我敢寫包單一定引起大量反對而被灌(○)保留票。第二項:不要吃掉後面的「等」字——這表示不限於企业与建築啊!如果衹限企业与建築,Grand Prix Macau馬上10點都不符合。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年5月27日 (一) 06:39 (UTC)[回复]
            • 首先,AFD非投票(笑)。針對首項,我認為可以建議提請人在快速刪除模板上提供相關連結或字典頁碼供查證(技術上可行;但通常RDRNC首項都是用來處理諸如Monkey、Apple之類的東西,那時就沒大必要這樣做)。針對次項,我認為須有一定合理數量的外間來源證明該名稱的關注度(例如Grand Prix Macau是否長期在非港澳來源中被提及)。同時針對兩點而言,既然社羣只容許十類外文重定向不被刪除,那就代表社羣對外文重定向有負面的傾向;我認為管理員有足夠能力判斷哪些是毫無疑問可被刪除,哪些應轉交AFD或駁回(例如Sunflower很明顯屬於前者,字典可查且非著名公司之非中文名;Oganesson就很明顯在正常字典不可查,理當駁回),只因少數例子而要讓社羣在大部分個案上浪費時間並不理想。Σανμοσα 2019年5月27日 (一) 08:55 (UTC)[回复]
              • 第一項:就算要按您的做法,仍然不可避免要放在存廢討論,因為如果有關證據放在速刪頁裏,所提供的證據在速刪的同時也會被一起刪掉,往後的人根本不易得知為何會違反第一項。第二項:如果衹是說「一定合理數量」如此抽象的話,那就更應該放在存廢討論,因為如何謂之合理,社群一定會有很多不同見解,情況有如條目陷入Wikipedia:關注度問題被討論一樣。另外,如上開出的刪除條件在我而言其實殊不簡單,對管理員來說明顯是個燙手山芋(至少Sunflower和Oganesson我不覺得一眼就能看得出來很明顯),故不管這兩類情況是多是少,我都不認為這兩類的刪除適合憑管理員一己之力判斷。還有請留意:有負面傾向並未必就一定有免討論快速刪除的傾向。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年5月27日 (一) 09:49 (UTC)[回复]
                • 回覆如下:
                  1. Twinkle執行的速刪留下的摘要應會附有相關證據;另外,任何人都可以向管理員查詢當時速刪是否有附加理由。
                  2. 我認為這些討論其實應該是要在DRV(而非AFD)進行的,因為在頁面存廢中,舉證責任在於支持保留方。
                  3. 我不認為管理員沒有使用搜索器簡單搜索字詞的能力。
                  4. 但至少這已説明了社羣傾向刪除如此重定向,而此已構成訂立速刪新例的基礎。這個是在長時間實行共識後很自然產生的一種因果關係。
                • 以上。Σανμοσα 2019年5月27日 (一) 14:50 (UTC)[回复]
                  • 我認為這些討論其實應該是要在AFD進行的,誰說頁面存廢的舉證責任衹在於保留方?頁面存廢討論的舉證責任是刪除和保留雙方面都有的,提刪者在寫理由時已經就有責任論證。更重要的是因為Wikipedia:刪除方針:「刪除決定不應輕易地做出……刪除應該是最後的選擇」,就拿回第一和二項為例,顯然地是與現有的速刪條款折然不同——它們需要依靠外部證據來證明,衹要是外部的證據,無論如何都會有潛在議論的機會,那就必須要在刪除前得到釐清和社群認可,而不是反過來立即刪除了之後要求社群舉證原先的速刪理據有問題。這些要討論的事情竟不是在AFD入手而是在DRV,根本違背「刪除應該是最後的選擇」原則。而由於要經過AFD,討論編輯摘要有否附有相關證據和可否向管理員查詢已無意義,因為AFD已留下論證記錄。另外,評估外部證據從來就不衹是搜索幾下那樣簡單,管理員就算懂得搜索,還須判斷搜尋結果是否合用,況且各位管理員使用的搜索方法可能不盡相同,自然就很容易得出不同的去留結論;更不用說如果是由一般用戶們來搜尋的話會出現幾多異見。最後,我認為您濫用了「社群傾向刪除如此重定向」的基礎,社群已有一段長時間刪除了多個某類頁面,與社群已經接受了可以不用討論速刪某類頁面,未必產生直接的因果關係,因為當中還要視乎各次達成刪除的過程如何。如果長時間地每個達至刪除的過程都沒有一次出現過議論的,您才可以說這個有因果關係,否則衹要有一次過程是不同的,這個因果關係足以變得不可說下去。一個「果」可以是由多重的「因」造成,您不能衹拿其中某一個「因」而去推論一個「果」啊。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年5月27日 (一) 18:57 (UTC)[回复]
  • (-)反对 已有編者指出,部分外文重定向有參考等鏈入,不宜倉促速刪 Vakrieger♀留言2019年5月30日 (四) 06:16 (UTC)[回复]
  • (-)反对 WP:RDRNC本身就没有讲清楚,那十大情形固然可建立,非此十大情形是否允许建立?遑论速删。我最近遇到的情形即为超出那十种范围之外的,也就是西文人名的重定向条目。我主张,对于西文人名,应允许直接使用在行文中,这是很多学术文献的惯例。那么非中文重定向页便必然十分常见。所以你看,实际情况是很复杂的,总有条款规定不到的盲点,以方针形式赋予某些用户速删的权限是鲁莽的。Cswquz留言2019年5月30日 (四) 11:44 (UTC)[回复]
  • (-)反对:從WP:重定向#何時用重定向?便可以知道,其它語言的重定向原則上都是允許的,只有符合WP:R#DELETE的理由才可以被刪除,而從Wikipedia:投票/非中文重定向頁面第二次投票也可以知道,發起投票的原因是濫提刪,所以制定了WP:RDRNC那些一定不能刪除的情況,嚴格來說它是個快速保留標準,不符合那些標準不等於不允許建立。Cswquz的意見非常好,那個投票所說「若該項目不獲得通過:代表了該類重定向不可以建立,並將相關的重定向及消歧義一一提交刪除」實際只侷限於當時有被提起而沒有通過的項目才被禁止,其它沒有被提起的情況,只能視為未被表決,並不是視為沒有通過而必須禁止,所以「方針現時確實只允許建立該等外文重定向」其實是完全錯誤的講法。--Opky9407留言2019年5月30日 (四) 18:41 (UTC)[回复]
    • 你們真的是要當「不可以建立,並將相關的重定向及消歧義一一提交刪除」這句說話不存在的嗎?Σανμοσα 2019年5月31日 (五) 01:48 (UTC)[回复]
    • 还有,WP:RDRNC以外的WP:R的內容皆非方針指引,並無約束力。Σανμοσα 2019年5月31日 (五) 02:35 (UTC)[回复]
      • (※)注意 投票案原文如下:

若該項目獲得通過:若該項目不獲得通過:代表了該類重定向不可以建立,並將相關的重定向及消歧義一一提交刪除,除非它符合了原先的重定向規則,如果沒有任何一項項目獲得通過,則不需要成立審核小組。

我看確實沒有提及獲提交表決項目以外的重定向。 -- Vakrieger♀️留言2019年5月31日 (五) 06:50 (UTC)[回复]

人物的性別和性向

问题:人物分類在國藉、職業、性別和性向這四個維度上沒有一致的組合方式。有時會進一步區分性別和性向,有時不會,而且不是男異性戀的人特別容易被標出來。Wikipedia:人物分类方法的建議是「國籍+職業」,沒有提到性別和性向,實際上存在的很多分類是「國藉+性別+性向」或「國藉+性別+職業」。

我的觀點

  1. 目前的分類方法不一致,需要統一。
  2. 標示女性和少數性向或許有助於改善維基百科的性別偏誤,但從另一角度來看,男性和異性戀不用特別標,其他的就要特別標出來,這又是一種不平等。
  3. 一個人的性別和性向在很多時候不那麼重要,也沒有關注度。

建議

  • 方案一:所有人預設為不標性別和性向(我個人偏好這個做法)
  1. 只有當這個人受關注的原因包括性別或性向,才應該加入有關性別和性向的分類,例如瑪麗·雪萊的性別對女性文學史有重要意義、白先勇寫了重要的同志文學作品、漢武帝的雙性戀在中國文學中是一個重要典故,所以標注為Category:英格蘭女性作家Category:台灣LGBT作家Category:中國雙性戀皇帝
  2. 其他剛好是這個性別或性向的人都不應該列入,例如J·K·羅琳Category:英國女性作家林懷民Category:台灣男同性戀者,這裡性別和性向並不影響他們的關注度,應刪除,只留「英國作家」和「台灣舞者」。
  • 方案二:全部都必須標示
  1. 所有的分類都同時標上國藉、職業、性別、和性向。J·K·羅琳是Category:英國女異性戀作家、金庸是Category:香港男異性戀作家
  2. 缺少任一維度的分類一律只能作為上級分類。
  3. 所有沒資料佐證的維度一律預設為「不明」,例如蔡英文Category:台灣女性性向不明政治人物
  • 方案三:預設全部標示,但無佐證資料時允許不標
  1. 類似方案二,但在沒有資料佐證時可以跳過。
  2. 缺少維度的分類除了當上級分類,也收錄資訊不明的人,蔡英文歸入Category:台灣女性政治人物

以前的類似討論

  1. Wikipedia_talk:格式手册/传记#请讨论一下人物传记条目如何说明性别
  2. Wikipedia_talk:人物分类方法#关于人物类条目的【性别】

--Yel D'ohan留言2019年5月22日 (三) 18:32 (UTC)[回复]

提案人對分類機制似乎有很大的誤解。首先,分類沒有必要統一。英國女性作家分類出現的原因只不過是英國作家的數目太多,為了避免過多條目使用同一分類才作細分,性別作為簡易的二分法,當然經常用作細分之用。反過來說,如果使用分類的條目數並不多的話,也就沒有必要作出細分。因此,需要考慮到實際情況,而不是武斷地以統一為名,結果卻讓分類變得肢離破碎。其次,只標女性不標男性的說法並不準確,理論上分類應該兩性並列,不過如果考慮到某些分野女性過少或男性過少的話,以其一性別為主軸作分類也不能說是完全無法接受。其三,少數性向正正因為是少數才會標記,那是因為多數根本沒有必要標記,數目過多會導致分類無法發揮作用,所以諸如什麼異性戀云云,在我看來都是多餘。其四,分類與關注度無直接關係。其五,您的分類方法含有大量需要判斷的地方,例如「漢武帝的雙性戀在中國文學中是一個重要典故」,就當您說的是真實,中國文學典故與史實不應混同,那只是漢武帝在文學上的形象,不一定與史實相似,而且年代久遠的情況下,要判斷漢武帝是否雙性戀也有相當的困難,更甚是雙性戀這個觀念在當時根本可能尚未出現,結果就變相成了原創研究,其他諸如「重要意義」、「重要的同志文學」等等,怎樣才算是「重要」?怎樣判斷?由誰判斷?如果有人覺得不重要的話,那您的分類標準也無法成立。最後,分類的建立需要同時考慮到跨維基分類之間是否能夠聯繫起來,您的方案會導致過多分類出現孤立的情況,導致大量條目難以被準確分類。以上,謝謝。—AT 2019年5月23日 (四) 11:55 (UTC)[回复]
我完全同意條目不多的話就不用再細分,如果要避免孤立的話,我的方案一和方案三可以簡單加入「只有當這樣分類的人大於 X 個,才設定該分類」。但是現有的分類情況,男作家是「作家」,女作家是「女性作家」有兩個問題。第一,在性別(或性向)比例不一致的時候,把少數性別獨立出去並不是最均勻的拆分方式。如果是為了避免分類中有太多條目,應該要被拆出來的是多數方而不是少數方。當你把「女性作家」和「LGBT作家」獨立出來,剩下的「作家」數量會遠多於另兩個分類,反之,如果拆成「作家」和「異性戀男性作家」的話,兩個分類的數量會更接近一半一半。第二,如果只將少數方獨立出來,這種差別待遇會強化不平等,是一種歧視,不是維基百科該做的,恕我不讚同「正因為是少數才會標記,那是因為多數根本沒有必要標記」的說法。至於分類判斷的部份,我用漢武帝當例子只是因為現在條目上有「雙性戀者」的分類,他實際上是不是雙性戀不是我要討論的問題。重不重要確實偏向主觀,但所有的分類本來就都是主觀的。不管是職業、生物物種、語言、國家、大氣現象、天體、學科……。甘蔗、蕃茄和小黃瓜算不算水果?草莓和蓮霧(假果)算不算果實?出來選過一次里長的人算不算政治人物?參加過幾次遊行才算社運者?本來就都是交給多數人或少數權威人士的主觀認定。重不重要可以自由心證,有爭議時再討論就好。 --Yel D'ohan留言2019年5月24日 (五) 12:02 (UTC)[回复]
又想到一點:如果只是要拆分人物太多,那我們也可以用出生年代、星座、血型、婚姻狀況、宗教、身高、政治立場、族裔、收入等其他方法,其合理程度和用性別或性向來細分是差不多的。--Yel D'ohan留言2019年5月24日 (五) 13:13 (UTC)[回复]
實際上,現存分類中同時存在Category:男性作家Category:女性作家,所以您擔心的問題其實並不存在。至於,細分方法我建議參照英維(或是說各維的做法),以免出現孤立的情況。—AT 2019年5月27日 (一) 09:25 (UTC)[回复]
三个方案都不合适。同上,分类名“+性别”大多是是因为分类下条目过多而被细分,仅男/女被细分也是因此,不是有意产生的“性别偏误”,只是一种省事(减少移动分类)的举动,补上另一分类即可纠正。“+性向”在我看来没有意义,且极易争议或涉在世人物隐私,除非LGBT等主题的分类有特殊需求。条目和信息框中是否声明人物性别,在我看来更值得讨论,很多时候读者看不出人物的性别;性向标识同上。最好的方案是开发出小工具(和提醒调用模板),在分类页面直接依赖维基数据的数据项查询并过滤性别、性向等条件,会更加方便并易于管理(全域共享、数据项格式约束、单个数据项支持多条参考来源),到那时,分类名的“+性别”很可能就多余了。--YFdyh000留言2019年5月24日 (五) 12:10 (UTC)[回复]
性別的部份,這種省事的方法是一種無意識偏見,不宜淡化。補上另一分類也不見得就能糾正,因為會有跨性別或非二元性別的人(在西方國家這佔大約 1% 的人口)。性向的部份我完全同意不放入分類,除非在是活躍於LGBT社群或史上第一個出櫃之類情況。--Yel D'ohan留言2019年5月24日 (五) 13:13 (UTC)[回复]
这种划分只是为了细分分类,如有無意識偏見也非有意为之,不宜过度认知。少数的特殊性别,完全可以不做细分(留在父/母分类),如果做细分,反而还有过度突出(比重平衡)和认知/划分偏差等问题,而且特殊性别是超过上百种的。“史上第一個……”也无需,除非特殊分类下且有需求,新分类下成员很少,也是不能细分的。过度认知下,特定条目/分类没有被预先创建或平衡摆放,也能扣上“無意識偏見”吧。--YFdyh000留言2019年5月25日 (六) 00:35 (UTC)[回复]

关于关注度主题的继承问题

目前WP:N中关于关注度主题继承的描述是关注度既不能向上继承,也不能向下继承。子条目不能继承母条目关注度我认为没有太大问题,但母主题在子主题条目不存在的情况下(或子条目有关注度但一定不会建立)的情况下,例如专辑中某一首歌曲具有独立关注度但本身鲜见报导,或例如WP:DRV#五甲交流道中立交桥中某一道路有关注度但立交桥本身缺乏关注度。根据这样的情况,是否应该适当修改关注度继承的规定,希望大家能够讨论。--クオン·目安箱⚗·翡翠·鵺鳥·十姉妹·夜啼鳥 2019年5月24日 (五) 03:24 (UTC)[回复]

    • 我認為在子條目不存在的情況下可以接受「母繼承子」(例如基督教香港信義會心誠中學校內之基督教香港信義會榮光堂被古物古蹟辦事處列為香港三級歷史建築,符合WP:GEOFEAT特例這種尷尬情況)。Σανμοσα 2019年5月24日 (五) 06:37 (UTC)[回复]
    • 我認為不應修改,若子主題因某些原因比母主題更有關注度,那本來就是子主題其獨特性獲得的關注度,母主題並沒有幫助它獲得關注度。--吉太小唯Don't Say Lazy.TALK2019年5月24日 (五) 07:44 (UTC)[回复]
      • 如果子條目不存在,那就沒有繼承的問題,子主題算是母主題的一部份,關注度當然一起算。可以參考這個情況:微顎動物門底下只有淡水顎蟲一個已知物種,所有關於微顎動物門的資訊都來自淡水顎蟲。處理方式是把微顎綱、顎蟲目、顎蟲科、顎蟲屬、淡水顎蟲全部都重定向到微顎動物門,當作同一個條目。沒有人會爭說微顎動物門的關注度繼承自淡水顎蟲。條目名稱要叫作「淡水顎蟲」還是「微顎動物門」也沒差,反正條目內容是差不多的。--Yel D'ohan留言2019年5月24日 (五) 12:31 (UTC)[回复]
        • 我不知道生物主題怎麼運作,但看這情況母主題只包含一個子主題,要找的東西也只能從淡水顎蟲找到。但五甲交流道只有一個三國通道嗎?三國通道的關注度怎麼可以等於五甲交流道的關注度?一首歌特別出名,所以包含它的專輯都自然擁有關注度?我是無法贊同。--吉太小唯Don't Say Lazy.TALK2019年5月24日 (五) 13:01 (UTC)[回复]
          • 我是這樣想的:五甲交流道的關注度(A) = 三國通道的關注度(B) + 其地部份的關注度(C) + 五甲交流道這整個集合產生的額外關注度(D)。所謂「不能繼承」,不是說 A ≡ D,而是說關注度只能用在一個地方,如果 B 有了獨立條目,A ≒ C+D。--Yel D'ohan留言2019年5月24日 (五) 13:29 (UTC)[回复]
  • 在此得向各位說聲抱歉,看來我的覆核理由寫得不夠完整,可能也讓管理員誤會了我的意思,不過這不會改變現在的主要議題(母主題是否能繼承子主題的關注度),但我還是要澄清三國通道與五甲交流道的關聯,免得錯誤愈來愈大:
  1. 「三國通道」是一條獨立道路,不屬於任何交流道。
  2. 而我在覆核理由提到的是「五甲交流道銜接三國通道的匝道」,這個「匝道」才是共同屬於五甲交流道與三國通道。也就是說「五甲交流道銜接三國通道的匝道」皆為「五甲交流道」與「三國通道」的子主題。
以上,所以冀望各位能將描述的方向修正為「這個『五甲交流道銜接三國通道的匝道』的關注度是否能向上繼承至『五甲交流道』」,至於三國通道本身已有關注度來源可證實關注度,故不探討。--TimChen 初夏的東港之櫻邂逅 2019年5月24日 (五) 13:33 (UTC)[回复]
    • 那把我前面說的 B 改成「五甲交流道銜接三國通道的匝道的關注度」就好了,其他部份意見仍一致。換個例子,一張專輯的關注度等於其中每首歌的關注度總和,加上整體的額外關注,除非其中的歌已經有自己的條目。--Yel D'ohan留言2019年5月24日 (五) 13:29 (UTC)[回复]
  • 不同意。试想一下,如果一个母主题本身缺乏非一次可靠文献之深入介绍,而子主题有深入介绍,如果要写一个关于母主题的条目,并且严格按照维基的方针指引,会出什么事情?这个条目会是挂羊头卖狗肉的——因为按照WP:VWP:NOR,条目应当依赖有非一次可靠文献,这样的文献支持的文字也只能是关于子主题的。要么违反内容方针,要么写出一个符合内容方针但是文不对题的条目。显然这两者都不是我们所期待的。GNG的精神在这里依然是适用的——既然是子主题有可靠文献的深入介绍,那么就应该开一篇介绍子主题的条目,最多顺带提及一下母主题,决不能本末倒置。--Antigng留言2019年5月25日 (六) 02:17 (UTC)[回复]

規範簽名可用的HTML/XML Tag

近期簽名出現擴展HTML/XML Tag,或使用LaTeX以及LaTeX宏包的簽名,例如<score></score>,形如
{a' b' b' a' a' g' g' c' g' a'}
部分編者指出不當,但我認為可以被解釋成妥當,屬於模糊地帶,為了避免爭議

,根據Wikipedia:签名#外部链接与模板規定,我們應該避免會對伺服器資源影響的簽名,和Wikipedia:签名#外观的規定

  • 因為以下的原因,請不要在簽名中使用圖片:
    • 耗費更多的系統資源;
    • 減少可搜尋性,並且使從頁面複製文字更加困難;
    • 從實際資訊中潛在地轉移注意;
    • 在多數瀏覽器中,圖片不能隨文字縮放,會使該行比其他沒有使用圖片的高。
  • 建議對「加入由擴展功能提供的HTML/XML Tag(Help:HTML#解析器扩展标签)的簽名」進行管制。
  • <gallery></gallery>
  • <nowiki></nowiki>(可能可以容許)、
  • <pre></pre>
  • <categorytree></categorytree>
  • <charinsert></charinsert>
  • <hiero></hiero>
  • <imagemap></imagemap>
  • <inputbox></inputbox>
  • <math></math>
  • <ce></ce>
  • <chem></chem>
  • <poem></poem>
  • <score></score>
  • <section></section>
  • <graph></graph>
  • <indicator></indicator>
  • <templatedata></templatedata>
  • <templatestyles></templatestyles>(已禁止,指引連結WP:SIG#TLCSS)、
  • <mapframe></mapframe>
  • <maplink></maplink>
  • <quiz></quiz>
  • <ref></ref>
  • <references/>(Self-Closing Tag)、
  • <syntaxhighlight></syntaxhighlight>
  • <source></source>
  • <timeline></timeline>
  • <big></big>
  • <br/>
  • <center></center>
  • <hr/>
  • 建議禁止的其他HTML/XML Tag:
  • <div></div>

個別HTML/XML Tag 簽名示例

請不要從這個段落進行編輯,請至下方討論區,感謝配合。--宇帆留言·歡迎簽到R₁R₂NKC2019年5月27日 (一) 10:01 (UTC)[回复]
  • 沒有使用任何HTML/XML Tag 簽名效果:
    正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
    我是留言 --簽名 2019年5月26日 (日) 10:28 (UTC)
    正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

  • <gallery></gallery>簽名效果:
    正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
    我是留言 --
  • 2019年5月26日 (日) 10:28 (UTC)
    • 正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

    • <nowiki></nowiki>簽名效果:
      正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
      我是留言 --[[User:Example]] 2019年5月26日 (日) 10:28 (UTC)
      正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

    • <pre></pre>簽名效果:
      正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
      我是留言 --
      簽名
      2019年5月26日 (日) 10:28 (UTC)
      正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

    • <code></code>簽名效果:
      正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
      我是留言 --簽名 2019年5月26日 (日) 10:28 (UTC)
      正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

    • <categorytree></categorytree>簽名效果:
      正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
      我是留言 -- 2019年5月26日 (日) 10:28 (UTC)
      正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

    • <charinsert></charinsert>簽名效果:
      正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
      我是留言 --簽名 2019年5月26日 (日) 10:28 (UTC)
      正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

    • <hiero></hiero>簽名效果:
      正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
      我是留言 --
      A1
      2019年5月26日 (日) 10:28 (UTC)
      正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

    • <imagemap></imagemap>簽名效果:
      正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
      我是留言 --
      Alt text
      2019年5月26日 (日) 10:28 (UTC)
      正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

    • <inputbox></inputbox>簽名效果:
      正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
      我是留言 --

      2019年5月26日 (日) 10:28 (UTC)
      正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

    • <math></math>簽名效果:
      正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
      我是留言 -- 2019年5月26日 (日) 10:28 (UTC)
      正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

    • <ce></ce>簽名效果:
      正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
      我是留言 -- 2019年5月26日 (日) 10:28 (UTC)
      正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

    • <chem></chem>簽名效果:
      正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
      我是留言 -- 2019年5月26日 (日) 10:28 (UTC)
      正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

    • <poem></poem>簽名效果:
      正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
      我是留言 --

    簽名

    2019年5月26日 (日) 10:28 (UTC)
    • 正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

    • <score></score>簽名效果:
      正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
      我是留言 --
      {a' b' c' d' e' f' g'}
      2019年5月26日 (日) 10:45 (UTC)
      正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

    • <source></source>簽名效果:
      正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
      我是留言 --簽名
      [[User:Example]]
      2019年5月26日 (日) 10:28 (UTC)
      正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

    • <mapframe></mapframe>簽名效果:
      正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
      我是留言 -- 簽名,歡迎來我家
      地图
      我家在這
      2019年5月26日 (日) 10:28 (UTC)
      正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

    • <maplink></maplink>簽名效果:
      正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
      我是留言 -- 簽名,歡迎來我家我家在這 2019年5月26日 (日) 10:28 (UTC)
      正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

    • <quiz></quiz>簽名效果:

     

    正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
    我是留言 --e约为

    2019年5月26日 (日) 10:28 (UTC)

    • 正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

    • <ref></ref>簽名效果:
      正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
      我是留言 --簽名[1] 2019年5月26日 (日) 10:28 (UTC)
      正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

    参考資料

    1. ^ 以上是User:Example的簽名

    • <references/>簽名效果:
      有參考文獻的討論blablabla[1]
      正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
      我是留言 --簽名
    • ^ 這個文獻會影響有使用<references/>的簽名
    • 2019年5月26日 (日) 10:28 (UTC)
      • 正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

      • <syntaxhighlight></syntaxhighlight>簽名效果:
        正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
        我是留言 --簽名
        for(int i=0; i<10; ++i);
        
        2019年5月26日 (日) 10:28 (UTC)
        正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

      • <timeline></timeline>簽名效果:
        正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
        我是留言 --
        User:Example
        2019年5月26日 (日) 10:28 (UTC)
        正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

      • <div></div>簽名效果:
        正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
        我是留言 --
        簽名
        2019年5月26日 (日) 10:28 (UTC)
        正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

      • <span></span>簽名效果:
        正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
        我是留言 --簽名 2019年5月26日 (日) 10:28 (UTC)
        正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

      • <p></p>簽名效果:
        正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
        我是留言 --

        簽名

        2019年5月26日 (日) 10:28 (UTC)
        正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

      • <section></section>簽名效果:
        正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
        我是留言 -- 2019年5月26日 (日) 10:28 (UTC)
        正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

      • <abbr></abbr>簽名效果:
        正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
        我是留言 --簽名 2019年5月26日 (日) 10:28 (UTC)
        正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

      • <blockquote></blockquote>簽名效果:
        正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
        我是留言 --

        簽名

        2019年5月26日 (日) 10:28 (UTC)
        正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

      • <cite></cite>簽名效果:
        正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
        我是留言 --簽名 2019年5月26日 (日) 10:28 (UTC)
        正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

      • <dd></dd>簽名效果:
        正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
        我是留言 --
        簽名
        2019年5月26日 (日) 10:28 (UTC)
        正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

      • <ol><li></li></ol>簽名效果:
        正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
        我是留言 --
        1. 簽名
        2019年5月26日 (日) 10:28 (UTC)
        正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

      • <table></table>簽名效果:
        正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
        我是留言 --
        2019年5月26日 (日) 10:28 (UTC)
        正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

      • <dfn></dfn>簽名效果:
        正常的留言 --正常的簽名 2019年5月26日 (日) 00:00 (UTC)
        我是留言 --簽名 2019年5月26日 (日) 10:28 (UTC)
        正常的留言 --正常的簽名 2019年5月26日 (日) 11:00 (UTC)

      討論區

      簽名中使用LaTeX

      • (!)意見LaTeX 相關 HTML/XMLTags在參數設定上可以設定成沒有圖片的樣式,例如Special:参数设置#mw-prefsection-rendering中有一個「LaTeX 原始碼」選項,因此部分位於WP:簽名#外觀中的部分理據是站不住腳的,因此說「使用了圖片」我覺得不妥,因為那不是「圖片」而是「LaTeX」。此外,我補充一點,直接複製該區域會獲得LaTeX原始碼。--宇帆留言·歡迎簽到R₁R₂NKC2019年5月26日 (日) 19:15 (UTC)[回复]
      • (:)回應:感谢关注。我对HTML和XML不怎么了解,但决定用这个签名之前肯定也是一句句对过方针指引的。我说一下我稍微懂一点的地方,不懂就不说了。当然说的也很可能错,还望诸位海涵。当然不想涵也可以不涵。
      1. 系统资源:我在沙盒试的时候,这一个签名差不多一百字节。
      2. 第二条:不懂,不说。
      3. 转移注意:其实说实话,要不是之前(应该)没人用过这个,乐谱当签名,这比五颜六色大红大紫的艺术字不显眼多了,为此我还特地采访了我的三位室友,他们对这句实话表示了肯定。
      4. 会使这行更高:1.5倍行高。换完签名以后我一直用手机做小编辑,感觉没什么大区别。蓝桌型签名似乎也是1.5倍行高,往下翻就有,正下方的话题讨论。实际上这签名在我参数设置里的显示是前后各空一行,就是乐谱自己必须占一行。这肯定不行啊,本来想换的,结果早上起来忘了这事,在dykc投票时候,惊喜地发现在设置外面它是不空行的。天上掉黑猫一样的愉悦。
      个人态度,(+)支持讨论一个统一标准,(-)反对逼我换签名。在没有明确的方针指引论述讨论共识要求我换签名的时候以明显不符合规范为理由要求我换签名是明显不符合规范的。在大管理员习加同志以明显不符合规范的理由要求我换签名的明显不符合规范的留言底下再复读一遍以明显不符合规范为理由的明显不符合规范的要求当然也是明显不符合规范的。
      {a' b' b' a' a' g' g' c' g' a'}
      2019年5月27日 (一) 04:43 (UTC)
      User:A2569875/個別HTML與XML Tag 簽名示例/擴展Tag為例,在電腦版上,正常的簽名高度為24px(以<dd>元素為準),含有score的簽名是52px,比原本高度的2倍還高,另score的展開結果為圖片,符合Wikipedia:签名#外观中禁止圖片的理由。--Xiplus#Talk 2019年5月27日 (一) 05:05 (UTC)[回复]
      (:)回應,我仍然覺得,他是一個LaTeX。--宇帆留言·歡迎簽到R₁R₂NKC2019年5月27日 (一) 05:25 (UTC)[回复]
      (?)疑問U:YFdyh000有甚麼看法?--宇帆留言·歡迎簽到R₁R₂NKC2019年5月27日 (一) 05:27 (UTC)[回复]
      注意:在手機版上一般文字為36px,因此52px是144%,看起來較能接受,但在電腦版上是216%。--Xiplus#Talk 2019年5月28日 (二) 00:16 (UTC)[回复]
      • 個人認為,<math></math>(數學)和<ce></ce><chem></chem>(化學)最後只出現學術符號,方針也沒有規定,認為可接受。但<score></score>(樂譜)最後出現樂譜,嚴重影響排版。另在下認為含樂譜的簽名出現圖片,樂譜不完全是圖片,在下對含樂譜的簽名出現圖片表示(=)中立。--KMB-ATENU139 討論2019年5月27日 (一) 09:10 (UTC)[回复]
      就个人观感来说,游魂的签名美观度还好、挺有特色的,高度是稍微高了一点,但没有阶梯状(大大小小)我觉得还行,比花花绿绿好+1。
      “禁止圖片的理由”有讲述原因,“耗费更多的系统资源”可以细分:1. 如果性能和缓存良好、技术人员没有抱怨,我觉得不必太在意。2. 我认为设立的一大本意是,不要为了个人签名用途,上传图片到中文维基/维基共享并调用。3. 对少数流量有限或低端设备用户有影响,不过他们访问其他页面时也很容易遇到图片、长条目,应该自有解决方案。“减少可搜索性,并且使从页面复制文本更加困难;”,我觉得一般般,不确定搜索能否匹配到目标(用户页)。复制比纯图片好一点点,但只是一点点,复制时看不出发言人,只是很多人的签名都有类似问题——与用户名不相关。“潜在地转移注意”有少许,但相比花花绿绿、宣传式,我觉得好很多了。“在多数浏览器中,图片不能随文本缩放,会使该行比其他没有使用图片的高。”,我没看到不能缩放,取决于设备环境。
      就设立而言,赞成“不建议”或“不应”,但以“指引”来一刀切“禁止”,会否过于严格。或者说,我赞成他目前的签名是“不过也可能存在偶发的例外”,但如果社群大多数认为这种签名不值得存在,我也接受。--YFdyh000留言2019年5月27日 (一) 09:29 (UTC)[回复]
      图片如果能控制在某一行距之内,我觉得可以接受。--Leiem签名·留言 2019年5月27日 (一) 14:59 (UTC)[回复]
      (:)回應@Leiem根據Wikipedia:签名#外部链接与模板的「要點」,我們必須「確保簽名存檔後不會因為其他頁面被改動而造成簽名出現變化」,因此這種形況我認為不能容忍「[[File:]]」形式的簽名,因為它事實上是將它頁的content包含進來,當圖片覆蓋、重新上傳後,簽名就會發生變化,而LaTeX則不一樣了,LaTeX不能透過編輯其他條目使其「包含的內容」發生「大幅變更」,或若有人能將<timeline></timeline><graph></graph><mapframe></mapframe>調整得小於255位元組、沒有外部連結、沒有模板、沒有模組也沒有破壞排版、沒有不明段行,行高也很矮的話,我倒是能(+)支持,但若是引用「[[File:]]」的圖片,我(-)反对;此外,(+)支持簽名限制使用LaTeX。--宇帆留言·歡迎簽到R₁R₂NKC2019年5月27日 (一) 15:44 (UTC)[回复]
      • (&)建議:喵喵喵我是藪貓。-- 瑪莉歐RIP
        \relative c'' { #(set-global-staff-size 6) \tempo 4 = 144 <b g g,>8[ <f' b,> r <f b,>] \tuplet 3/2 { <f b, g,>4\( <e a,,> <d b,>\) } << { c2 r } \\ { c,8 g e g c,4 r } >> }
        2019年5月27日 (一) 19:27 (UTC)
        • (!)意見:我可以解離成碳酸根氫正離子哦。-- 我喝碳酸 2019年5月27日 (一) 19:27 (UTC)
          • (:)回應:嗯吶啊,我是娜娜奇,好棒喔,樓上上簽名可以用「瑪莉歐RIP」搜索;樓上可以用「我喝碳酸」搜索。 -- User:娜娜奇 2019年5月27日 (一) 19:27 (UTC)
      • 行高问题肯定存在,但差距并不明显,我不觉得需要在没有明确危害的前提下依指引严格要求和禁止。且该例并没有扰乱指引举例的“文字”排版(如高低错落或折行),指引也未明确约定行高限制为200%,加之当前此处没有共识。禁用图片的目的上方有讨论过了,渲染结果为图片比较难说符合指引立意之图片(如File:)。@Xiplus,系统资源层面也是符合的,扩展渲染成图片和网络传输给用户。搜索问题,很多人的签名文本也是很难找到原主人的(尤其是依外观找出本来用户名),这在目前还是一个常见问题,轻微转移注意力同上。缩放问题,暂未见到抱怨,如有应考虑,但也要注意,很多人的签名以及众多页面、模板也并没有良好的网页亲和力,单就此例禁止也许吹毛求疵。如果游魂能将乐谱缩小些(技术是否不支持?)、追加一些文字和链接(哪怕如🎵),应该更为大家所接受。上方宇帆提出的用例很不错,字号12下的“
        { #(set-global-staff-size 12) {a' b' b' a' a' g' g' c' g' a'} }
        ”高度31px,是否好很多。--YFdyh000留言2019年5月27日 (一) 18:32 (UTC)[回复]
      • 2倍高叫「差距并不明显」?那麼請解釋指引說避免使用font-size:200%的用意?字号12 高度31px,為原本的130%我認為是可接受的;追加一些文字和链接也能增加可搜尋性。--Xiplus#Talk 2019年5月28日 (二) 00:09 (UTC)[回复]
      • “未明确约定行高限制为200%”,而“指引”禁止例子为200%,且不单纯是字号限定,更多是排版问题,所以我觉得250%以内都可商榷(当然具体看社群和泛滥程度),以及之前大体积或稀奇古怪的签名也不是没有过,似乎没有引起多少反映。--YFdyh000留言2019年5月28日 (二) 18:50 (UTC)[回复]

      初步共識

      現行條文

      外观 基于页面美观的原因,您的签名请遵守以下规范:

      • 应避免采用这些标记,例如<big><span style="font-size:200%;">(或者更多)的标签(这是BIG标签的文本),这样做会扰乱文本的显示方式;
      • 请避免添加换行标记(<br />)、水平居中标记(<center>...</center>)以及类似的其他标记,这也会严重影响附近文本的显示。提倡使用不换行空格,以保证在同一行中显示您的签名;
      • 最好避免您的签名太小,以至于难以阅读;(如很小的文本
      • 应避免使用多重上标或下标,这些脚本也会影响文本的显示方式;(多达N次多达N次
      • 请勿添加水平线标记(如<hr />)。

      长度

      提議條文

      外观 基于页面美观的原因,您的签名请遵守以下规范:

      • 应避免采用这些标记,例如<big><span style="font-size:200%;">(或者更多)的标签(这是BIG标签的文本),这样做会扰乱文本的显示方式;
      • 请避免添加换行标记(<br />)、水平居中标记(<center>...</center>)以及类似的其他标记,这也会严重影响附近文本的显示。提倡使用不换行空格,以保证在同一行中显示您的签名;
      • 最好避免您的签名太小,以至于难以阅读;(如很小的文本
      • 应避免使用多重上标或下标,这些脚本也会影响文本的显示方式;(多达N次多达N次
      • 请勿添加水平线标记(如<hr />)。

      HTHL/XML標籤 除了上述規定需要禁止的HTHL/XML標籤(<big></big><br/><center></center><hr/>)以及隱含引入圖像的HTHL/XML標籤(包括但不限於<gallery></gallery><imagemap></imagemap>等)之外,並沒有限制對其他HTHL/XML元素的使用。 例如目前並未禁止在簽名中使用與LaTeX相關擴展標籤生成的非文字渲染結果,例如<score></score><math></math>等,但必須符合下列規範:

      • 渲染結果的行高不應超過其他行的2倍
      • 簽名結果必須是靜態的,也就是說不能因為其他頁面被編輯而發生改變,包含外部連結的影響,也必須確定現在的結果不會因為移動到他頁而發生變化(例如討論串被存檔)
        • 這意味著,您的簽名不能隱含包含任何來自File:名字空間的內容、不能使用<categorytree></categorytree>將分類內容包含入簽名、不能使用模板模組輸出內容、也不能使用會發生變動的WP:魔術字,靜態的WP:魔術字則不在此限。
      • 必須確保在篇幅允許的情況下簽名能在同一行顯示,換句話說您的簽名除了因篇幅因素造成的換行效果外,不能有其他的換行現象出現。
      • 您的簽名必須出現至少一個不是由擴展標籤渲染出的部分,例如使用LaTeX必須至少在簽名中加入一個或多個非LaTeX字符或其他純文字。
        • 這是因為若簽名完全由擴展標籤渲染,則將會減少可搜尋性,並且使從頁面複製文字更加困難
      • 您的簽名不能干擾其他行的排版,比如不能出現置左、置中或置右等元素。

      此外,由於技術原因,您不應在簽名中使用下列HTHL/XML標籤:

      • <ref></ref><references/>(影響參註運作)
      • <noinclude></noinclude><includeonly></includeonly><onlyinclude></onlyinclude><section></section>(干擾部分要將討論嵌入他頁的運作)
      • <templatedata>(干擾templatedata運作)

      长度

      目前特色列表的评选分为三阶段,每阶段30天,若条目未凑齐8支持票则要进入下一评审期。也就是说FLC最多可达90天,这么长的时间给动员令等多方面都造成了困扰。而现在可见FLC的评选热度也在逐渐上升,很多列表甚至在基础评选期之内就凑足了8支持票。故我建议修改WP:FLC如下(相应地修改Template:FCpages/Preload_FLN):

      現行條文
      存档程序

      评选/重选期分三阶段,分别为基础评选期(30日)、初次延长期(基础评选期+30日)及最后延长期(初次延长期+30日),如参与投票的有效票数未能达到8票则将进入下一评选期。...

      提議條文
      存档程序

      评选/重选期分三阶段,分别为基础评选期(7日)、初次延长期(基础评选期+7日)及最后延长期(初次延长期+7日),如参与投票的有效票数未能达到8票则将进入下一评选期。...

      若对时间等方面有意见可以提出。--Rowingbohe♬Taichow·Sign 2019年5月26日 (日) 08:45 (UTC)[回复]

      現行條文
      存档程序

      评选/重选期分三阶段,分别为基础评选期(30日)、初次延长期(基础评选期+30日)及最后延长期(初次延长期+30日),如参与投票的有效票数未能达到8票则将进入下一评选期。...

      提議條文
      存档程序

      评选/重选期分三阶段,分别为基础评选期(14日)、初次延长期(基础评选期+14日)及最后延长期(初次延长期+32日),如参与投票的有效票数未能达到8票则将进入下一评选期。...

      @Rowingbohe你觉得这样如何呢。这样子就能压缩到60天了。影之诗 2019年5月26日 (日) 12:55 (UTC)[回复]

      現行條文
      存档程序

      评选/重选期分阶段,分别为基础评选期(30日、初次延长期(基础评选期+30日)最后延长期(初次延长期+30日),如参与投票的有效票数未能达到8票则将进入下一评选期。...

      提議條文
      存档程序

      评选/重选期分阶段,分别为基础评选期(14日)及延长期(基础评选期+14日),如参与投票的有效票数未能达到8票则将进入下一评选期。...

      以上。除此方案外,我還支持的方案有14+14+14、14+14+28和15+15+30。Σανμοσα 2019年5月27日 (一) 09:08 (UTC)[回复]

      啟用修訂巡查的阻礙

      基於現時暫時不能安裝此擴展的因素,修訂巡查極可能不會在6月1日開始試行。現於下面討論解決方法。--1233 T / C 2019年5月29日 (三) 09:04 (UTC)[回复]

      • 基金会不同意在新维基开启这个扩展我们也没有办法。至于下次,我看在客栈讨论这类技术问题前最好是问了基金会技术人员可行性。关于条目被破坏,只好过滤器,机器人禁封等途径。或者一个建议,开启一个保护程度,IP不能编辑,注册用户可以编辑,4/0,这个也不懂可以吗?--Cohaf(talk) 2019年5月29日 (三) 09:12 (UTC)[回复]

      提議更新WP:RDRNC

      參見Wikipedia:頁面存廢討論/記錄/2019/05/29的紀錄,KirkLU根據規範提刪大量外文重定向的條目,唯在檢視及考量實際搜尋體驗時,認為該規範並不能包含所有合理的範疇,且提刪弊大於利,因此提出現行規範的疑慮。過去討論12皆已超過10年,在下認為有重新討論的可能性,理由如下:

      • 現行規範對於外文人名及地名的規範缺乏:早年維基百科也許創建的條目皆以名人為主,能夠輕易地搜尋到相對應的中文名。但隨維基百科的規模擴張,中文維基充滿大量原創譯名,大幅提升搜尋上的困難度。因此在下認為有改善搜尋效率的必要,以避免條目重複創建,為了沒有意義的堅持(浪費網路資源?)增加搜尋文章的成本。

      因此提議放寬外文重定向的限制,將外文人名(含台灣原住民人名羅馬拼音)、外文地名納入方針的容許範圍之中。---Koala0090留言2019年5月30日 (四) 12:12 (UTC)[回复]

      提案討論

      提案1:修訂「國際性」之規範

      鑑於WP:RDRNC目前表述較為模糊

      且該等模糊已經引起爭議

      在下提議以更明確的條文代替WP:RDRNC第2、第5條。

      現行條文

      2. 國際性:國際知名的企業、建築等:像Yahoo!→雅虎、McDonald's→麥當勞、Coca-Cola→可口可樂等等。
      5. 作品:原文名稱知名度遠大於中文譯名者,如Harry Potter→哈利·波特、Final Fantasy→最終幻想系列、The Lord of the Rings→魔戒等。

      提議條文

      2. 具國際關注度的專有名詞(含企業、建築、作品、人名等),並符合下列條件:

        1. 前10大維基百科語種至少5種包含相應條目
        2. 中文維基百科對應條目內註明外文名且與重定向相同或十分相似

      歡迎大家參與討論。 -- Vakrieger留言2019年5月30日 (四) 12:27 (UTC)[回复]

      提案2:在條目名稱譯為譯名的情況下,容許相對應的外文重定向建立

      • 我提議只要是「譯名」或「非漢語轉寫」(包含原住民、少數民族)就應該容許外文重定向,且為了符合現狀,若原文為拉丁字母以外的語言,應該容許拉丁字母的拼寫重定向。---Koala0090留言2019年5月30日 (四) 12:41 (UTC)[回复]
      現行條文

      (無)

      提議條文

      12. 凡條目名稱譯自漢語外之譯名,在正確、可查證、沒有歧義的前提之下,可容許對應外文重定向建立。若原文為拉丁字母以外的語言,亦容許拉丁字母的拼寫之重定向。

      • (-)強烈反对12,理由參考4個月前的失敗先例以及當中我的反對理由,這很明顯是失敗先例的翻版。Σανμοσα 2019年5月30日 (四) 13:02 (UTC)[回复]
        • 我其實沒有看到任何說服我的理由,我的提議並沒有放寬建立重定向的謹慎程度,任何譯名本來就應該有原文支持。---Koala0090留言2019年5月30日 (四) 13:08 (UTC)[回复]
          • 巡查員應該質疑外文名的真確性。Σανμοσα 2019年5月30日 (四) 13:12 (UTC)[回复]
            • @Sanmosa由於閣下似乎沒有認知到譯名建立外文重定向的重要性和意義,我仔細說明一下。任何音譯的結果都具有高度不穩定性,我們同一個原文材料有可能音譯為無限種音譯組合,特別是中文維基百科容許原創譯名的性質,更加深了這個不穩定的因素。因此強烈建議任何譯名都應該擁有對應的原文重定向,以維持譯名穩定性的基礎。另外「巡查員應該質疑外文名的真確性」這點與本次提案完全不衝突---Koala0090留言2019年5月30日 (四) 13:16 (UTC)[回复]
              • @Koala0090要我支持12也不是不可以,但我要求只限於沒有可靠來源提供中文譯名的情況下才能建立外文重定向,而且拉丁字母以外的語言的拉丁化外文重定向也必須有可靠來源提供如此的拉丁化方可建立。Σανμοσα 2019年5月30日 (四) 13:21 (UTC)[回复]
                • @Sanmosa 那麼前面加上「在有來源支持下」,然後要求將來源放在討論頁中這樣可以嗎?---Koala0090留言2019年5月30日 (四) 13:28 (UTC)[回复]
                • 舉例:假設塔納通·宗龍倫吉的現行譯名是原創出來的,那他的泰文原名“ธนาธร จึงรุ่งเรืองกิจ”的重定向就可以在我的前設下建立,因此“Thanathorn Juangroongruangkit”作為泰文原名的拉丁化名稱,並有此來源的情況下,也可以在我的前設下建立。然而,由於塔納通·宗龍倫吉的現行譯名是由此來源提供的,那他的泰文原名及其拉丁化的重定向在我的前設下就不可以建立。又如果塔納通·宗龍倫吉的現行譯名是原創出來的,但并無可靠來源提供任何泰文原名的拉丁化名稱,則“Thanathorn Juangroongruangkit”的重定向不可建立。Σανμοσα 2019年5月30日 (四) 13:32 (UTC)[回复]
                  • @Sanmosa即使是某一來源支持,也不能完全消除譯名的不穩定性,同一個外文人名可能有無限種的來源去支持不同的譯名。與其為無限種中文譯名加上重定向,不如直接加上拉丁文重定向和原文重定向,可以同時兼顧譯名穩定性和搜尋的便利性---Koala0090留言2019年5月30日 (四) 13:41 (UTC)[回复]
                    • @Koala0090但為無限種中文譯名加上重定向本就是社群正常做法,我認為無必要制止。Σανμοσα 2019年5月30日 (四) 14:09 (UTC)[回复]
                      • @Sanmosa首先,關於這樣的慣例是為了解決什麼樣的問題,其實中文維基百科一直都沒有一個合理的論述。回去看討論紀錄,所有反對外文重定向的理由階相當空泛,要不就是「浪費系統資源」,不然就是「這裡是中文維基百科」,但是前者已經為英文維基百科所駁斥,而後這並沒有包含任何有意義的論述。所以,接下來我不會贊同所有關於「慣例」和「正常作法」的論述,因為這並不是一個有效的理由和論述。我的每一個論點都有提出我希望解決的問題,如果你認為這些問題沒必要解決,或這些問題沒有眾要到應該解決,那麼應該提出關於這些論點的論述,而不是用一句空泛的慣例來回覆。---Koala0090留言2019年5月30日 (四) 18:04 (UTC)[回复]
                        • 如果重定向的目標是為了要讓等價或相當的項目做一個對應,而這些對應的優點是能夠減少搜尋成本,甚至避免條目的重複創建,那麼外文重定向的價值就會因此彰顯,且並無刪除的理由。---Koala0090留言2019年5月30日 (四) 18:04 (UTC)[回复]
                          • 怎樣說好呢?一個外國人的名字可能有多種譯法,但他的外文名稱在中文圈內沒太多人用(例如我們根本不會以「Thanathorn」這個字理解「塔納通」,因為華文媒體都是直接用「塔納通」指代本人,那就沒有建立外文重定向的必要性)。外國人的名字的多種譯法,很多情況下都是因為地區因素,而這樣標題就會有{{noteTA}}轉換,這時為了避免紅連,就無可避免地需要重定向(可幸的是,「塔納通」暫時只有一種譯法)。Σανμοσα 2019年5月31日 (五) 01:46 (UTC)[回复]
                            • @Sanmosa,好,你這樣說我就理解了,理由是你跟我的搜尋體驗不同。但包含我在內很多譯者是會讀外文文獻的,且有很多人名在中文文獻中會維持原文,而如果此時中文維基已經有譯者已經選定一個難以搜尋的譯名作為目標,那麼是不是大幅增加搜尋的困難度?例如格拉迪斯·朗茲伯瑞·霍比,這個譯名其實是有來源支持的,但是在網路上面根本搜不到啊,我們書上寫的全部都直接以他的原名Gladys Lounsbury Hobby來書寫,但按現行規定,這個名字就是留不下來。確實,如果不計心力的搜尋,我們仍然有機會搜尋到對應的中文條目,但為什麼需要這樣呢?今天因為你我都是維基人,對於這個介面很熟悉,那麼其它讀者呢?---Koala0090留言2019年5月31日 (五) 01:59 (UTC)[回复]
      • 針對Vakrieger提出的新版2,我認為該兩項附加要求都是不必要的(前者而言,前10大維基百科語種是可變動的;後者而言,這似乎更應該成為不具有强制性的建議)。另外,我在上面提出的RDRNC速刪提案現在並不包含第2、4、5、6項,這些都應該轉交AFD作深入討論。Σανμοσα 2019年5月30日 (四) 13:12 (UTC)[回复]
      • (+)支持 这是我一直以来的主张,也是诸多学术著作的惯例。注意这只是主张用重定向,以便给行文多提供一类选择、一道方便,主条目标题还是要用中文,所以并不违反中文维基的基本原则。
      • 语言,就是一个约定俗成的事,什么好用用什么。很多外文人名,由于书写、读音规则都五花八门,并不适合音译为汉字名,用原文更加方便。至于说要维护中文之类,我想说,要相信汉语的同化能力,而不必从一开始就定一个人为的标准。未来的人们自会发明更高效更通行的叫法。汉语中有大量的外来词,现在都以高频使用,可当初消化它们却经历了长时期的演变。
      • 除了相信汉语的同化能力,还要相信维基的自我纠错能力。我注意到,最近主张针对非汉语条目建立更苛刻方针的两位皆为巡查员。这似乎可以解释为:一个人手里如果拿着把榔头,那么在他眼里便到处都是钉子。权力的运用要奉行谦逊原则,尽量谨慎使用。巡查也只是一个人,不可能了解所有领域中的术语使用习惯,其知识水平也不会因被赋予巡查权限而获得明显提升。引发此议题的大量提删事件,事主的知识水平明显不足以评判他所提删的那一百几十条条目的存废(事实上,我怀疑有此能力的人的存在性),其错误正在于没有奉行谦逊原则。那位巡查员的一个论点是“非中文的错误重定向甚至是恶意重定向很难得到纠正”,对此我的看法是,如果一个错误的甚或是恶意的重定向因大部分用户英文不佳而没有获得纠正,那么也就意味着那些重定向词条没有什么取阅数,恶劣影响同样也就不大。Cswquz留言2019年5月30日 (四) 17:23 (UTC)[回复]
      Vakrieger的提議的限制還是有點定得太死了吧,建議放寬成這樣:
      現行條文

      2. 國際性:國際知名的企業、建築等:像Yahoo!→雅虎、McDonald's→麥當勞、Coca-Cola→可口可樂等等。
      5. 作品:原文名稱知名度遠大於中文譯名者,如Harry Potter→哈利·波特、Final Fantasy→最終幻想系列、The Lord of the Rings→魔戒等。
      11. 書籍、學術期刊的外文名稱重新導向至中文名稱。

      提議條文

      2. 外文名稱:如果該名稱有合理期望會被中文使用者在中文語境中使用,或者該外文名稱的中文翻譯未被所有地區和階層的中文使用者廣泛接受,或者該外文名稱對應主題的所在領域習慣以該外文語言稱呼相關主題,則可建立該外文名稱的重定向。

      註:外文並不限定為原文。——C933103(留言) 2019年5月30日 (四) 19:46 (UTC)[回复]

      (~)補充 我的第一條附加限制是對現有條文「國際知名」和「知名度遠大於」等說法的具體化,以免日後再發生爭議。第二條則是回應@KirkLU關於外文重定向太多難以巡查和驗證的顧慮。

      如果社群有共識,在下相當(+)支持取消這兩則附加限制。-- Vakrieger♀️留言2019年5月31日 (五) 01:20 (UTC)[回复]

      提案3:方針未涵蓋之非中文重定向的處理方案

      對於正確、可查證、沒有歧義,卻不在WP:RDRNC範圍內之外文重定向,我認為有必要明確如何處理。

      在下可以想到三種方案:

      1. 明確不禁止相關重定向,只是不鼓勵創建
      2. 原則上禁止該等重定向,但承認若重定向有用,仍然可根據「忽略一切規則」創建。方針不能被用於提刪的唯一理由。
      3. 禁止創建任何其他重定向。若有便提刪乃至速刪。

      本人傾向2。 -- Vakrieger♀️留言2019年5月31日 (五) 01:28 (UTC)[回复]

      既然有“忽略一切规则”之最高原则,那么第3条跟第2条就没有区别。Cswquz留言2019年5月31日 (五) 05:39 (UTC)[回复]
      (:)回應: 區別就是第二條規定「方針不能用於提刪的唯一理由」,提刪者必須舉證為何這個重定向沒有好處甚至有壞處。第三條則無此限制,舉證責任在創建者 -- Vakrieger♀️留言2019年5月31日 (五) 05:57 (UTC)[回复]