Wikipedia:互助客栈 (全部)

本頁互助客棧 (全部)是供以方便瀏覽所有討論而特別設置。如果您想要新增討論內容，請在互助客棧中選擇最合適的版面。

按此刷新頁面。

		歡迎光臨互助客棧！
	互助客栈是維基人議事相助之處，用以討論消息、方针、技术以及编辑、求助等議題。 發表議題之前請搜索先前文章，遵守指導及禮儀。任何與維基百科無關的問題，请前往知识问答。
消息	方针	技术	求助	條目探討	其他
討論維基相關新聞與消息	討論方針與草案	解決或報告技術疑難	解決在維基百科中所遇疑難	條目、模板、主題相關探討	未符任何分區之議題
发表 | 监视	发表 | 监视	发表 | 监视	发表 | 监视	发表 | 监视	发表 | 监视
查看全部討論
帮助目录 · 提出疑问 · 基础维基代码 · 常见问题 · 常见错误 · 了解术语 · 即时协助 · 規則简述 · 使用指南
维基百科社群 事务討論 方针提案 其他提案 协作讨论 提问 条目探讨 請求 专题 维护 部门 目录 帮助 规则 即时通讯 聚会
If you don't use Chinese, and want to contact Chinese Wikipedia, please leave your message here.

我想要……	请前往……
如何有效並安全地访问维基百科的方法	如何访问维基百科
与繁简处理有关的问题	字词转换
協助或尋求條目的改善意见	同行评审
对某些特定来源的讨论	可靠来源布告栏
寻找参考文献	文献传递
參與即時讨论或通过电子邮件进行讨论	「即時討論」或者「邮件列表」

---

消息

关于Wikibase的中文译名。请社群给参考意见。

参见 wikidata:Talk:Q16354758。需要中文使用者参与，谢谢🙏。~ viztor ✪ 2019年7月12日 (五) 20:43 (UTC)

• 在下以为已经有了“维基资料库”这个合适的名字。“维基数据库”和维基数据混在一起，而叫资料库没这个问题，还符合这个软件的性质。--痛心疾首（留言） 2019年7月13日 (六) 01:44 (UTC)
  • 数据库/資料庫 是地區詞差異。--Xiplus#Talk 2019年7月13日 (六) 01:53 (UTC)
• 叫维基基吧。--超级王（昔有地图开疆，今有易帜救国） 2019年7月13日 (六) 01:46 (UTC)
  • (＋)支持维基基，base本来就有基础的意思。--Gqqnb（留言） 2019年8月9日 (五) 01:17 (UTC)

由于与本讨论页或讨论主题无关，本框内討論文字已關閉，相關文字不再存檔。

如有異議，請諮詢互助客棧或其他管理員。執行人：-- Sunny00217 2019年7月31日 (三) 06:06 (UTC)

• • 说基不说吧，文明你我他^{[開玩笑的]}--Rowingbohe♬^{欢迎参加第十七次动员令}_台州专题 2019年7月13日 (六) 02:51 (UTC)
  • (－)反对維基基。至少據我所知，基這個發音重複兩次在臺灣是不雅詞彙。如果真的要維基基，可能「維基本」更好，有，基本之意，或者「維基集」至少聽起來不是雞雞，是積極。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月13日 (六) 03:06 (UTC)
    • 我看你是太当真了。原来我给Wiki Loves Love起外号叫维基爱爱也没见这么大反映啊。--超级王（昔有地图开疆，今有易帜救国） 2019年7月14日 (日) 01:20 (UTC)
      • 维基爱爱沒有如上問題。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月14日 (日) 06:19 (UTC)
        • 所以爱爱和基基的区别在哪？--超级王（昔有地图开疆，今有易帜救国） 2019年7月14日 (日) 07:16 (UTC)
          • • 你自己看什麼是雞雞（臺灣用法），請尊重不同地區用法及文化。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月14日 (日) 07:35 (UTC)
              • 你就是太当真了，大陆也有这种用法。--Rowingbohe♬^{欢迎参加第十七次动员令}_台州专题 2019年7月20日 (六) 12:36 (UTC)
          • 请停止无意义的讨论，谢谢。~ viztor ✪ 2019年7月14日 (日) 07:27 (UTC)
            • 我不會再繼續回應此段。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月14日 (日) 07:35 (UTC)

• 数据库/資料庫 = database，所以wikibase = 維基庫？-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月13日 (六) 02:28 (UTC)
• 我看mw上面的介绍，叫资源库会不会好点。--Hamish歡迎來訪 2019年7月13日 (六) 02:53 (UTC)
  • (＋)支持资源库 or 维基资源库。维基库尚可接受。--Rowingbohe♬^{欢迎参加第十七次动员令}_台州专题 2019年7月13日 (六) 05:54 (UTC)
• 维基贝斯、维基总部、维基纵横、维基倍思、维基大表、维基库、维基物语 Bluedeck 2019年7月13日 (六) 02:55 (UTC)
  • 都很爛-- Sunny00217 - 2019年7月22日 (一) 08:32 (UTC)
• (＋)支持維基資源庫（或者維基資源），看了簡介，資源庫更合適，但維基庫可能會和維基文庫搞混。（維基物語是甚麼鬼）--【和平至上】💬📝 2019年7月13日 (六) 17:08 (UTC)
• 維基資源/維基資源庫会不会和维基共享资源混淆？--百無一用是書生 (☎) 2019年7月15日 (一) 03:06 (UTC)
• 那維基架構如何？--【和平至上】💬📝 2019年7月15日 (一) 13:13 (UTC)
• 或者維基支援庫、維基結構化資源庫（區分其他項目惟略長）、維基結構化庫、維基結構庫。--Hamish歡迎來訪 2019年7月15日 (一) 18:16 (UTC)
• 較為傾向「維基庫」。산모사 ^DC17_{FLC GAC} 2019年7月19日 (五) 09:29 (UTC)
• 傾向支持維基資料庫。—— Eric Liu_{（留言．留名．學生會）} 2019年7月23日 (二) 05:09 (UTC)
• 按wikibase實際功能的話，「維基資料庫」一名較為合適。—Gompertz在原野上遨遊_{堅持五大訴求 連儂牆 請支持胡樂甫優良評選 請支持柯科迪優良評選} 2019年7月24日 (三) 02:06 (UTC)
  • 以我理解，wikibase的作用是讓其他計劃（如wikidata）能夠儲存結構化資料，而非儲存資料。不知道我的理解有沒有錯？如果是這樣的話，「維基資料庫」可能不合適。--【和平至上】💬📝 2019年7月26日 (五) 09:42 (UTC)
    • 那要叫「維基結構化資料庫」嗎？-- Sunny00217 2019年7月31日 (三) 06:09 (UTC)
• 资源库、资源容易与维基共享资源的功用混淆。资料库/数据库是地区词。“维基数据库（wikibase）为维基数据的底层”，也没问题。“维基库”含义模糊，以及这是个技术性用语，占用简洁的名称没什么好处。赞成“维基结构化(数据库)”，不一定要后缀“数据库”。如果不看功用只看名称，我会直译“维基基础”。“维基基础数据”？--YFdyh000（留言） 2019年8月11日 (日) 13:39 (UTC)
  • @YFdyh000：「維基基礎數據庫」會比較完整吧？-- Sunny00217 2019年8月15日 (四) 08:43 (UTC)
    • User:Sunny00217“基础数据库”感觉其他项目有依赖它，实则不然，没有库似乎能理解为提取、精炼的基础数据。有Wikibase database怎么办。“维基数据库”可以解释为它是一个数据库套件。--YFdyh000（留言） 2019年8月15日 (四) 12:02 (UTC)
  • (＋)支持-- Sunny00217 2019年8月15日 (四) 12:16 (UTC)
    • User:Sunny00217建议阐明支持什么，我也没有最终意见，并提出了多个可能方案。--YFdyh000（留言） 2019年8月16日 (五) 07:49 (UTC)

本章節暫時不存檔（直到討論完成）。移除{{Do not archive}}以讓機器人存檔。留言請置於本模板上方。

Wikipedia translation of the week: 2019-33

The winner this Translation of the week is en:Visby City Wall Please be bold and help to translation this article! Visby City Wall (Swedish: Visby ringmur, sometimes Visby stadsmur) is a medieval defensive wall surrounding the Swedish town of Visby on the island of Gotland. As the strongest, most extensive, and best preserved medieval city wall in Scandinavia, the wall forms an important and integral part of Visby World Heritage Site. Built in two stages during the 13th and 14th century, approximately 3.44 km (2.14 mi) of its original 3.6 km (2.2 mi) still stands. Of the 29 large and 22 smaller towers, 27 large and 9 small remain. A number of houses that predate the wall were incorporated within it during one of the two phases of construction. During the 18th century, fortifications were added to the wall in several places and some of the towers rebuilt to accommodate cannons. (Please update the interwiki links on Wikidata of your language version of the article after each week's translation is finished so that all languages are linked to each other.) About · Nominate/Review · Subscribe/Unsubscribe · Global message delivery 2019年8月12日 (一) 02:05 (UTC)

Flow(结构化讨论)无法恢复到旧版的Bug已经修复

先前在测试功能中关闭“用户讨论页上的结构式讨论”后仍无法恢复到旧版，经过phab:T229795这一bug应该已经修复。如欲将Flow恢复至旧版讨论页请重新在“测试功能”中重新选中启用、保存，之后再取消勾选关闭。抄送：@Emojiwiki、Antilovsky、Daniel J Zhao--及时雨 ^留言 2019年8月12日 (一) 04:25 (UTC)

Wikidata weekly summary #377

Here's your quick overview of what has been happening around Wikidata over the last week.

• Press, articles, blog posts
  • Conclusion of 7th Parliament of the 4th Republic of Ghana Wikidata Editathon (grant report)
  • "Creating Library Linked Data with Wikibase: Lessons Learned from Project Passage" OCLC Research. DOI: 10.25333/faq3-ax08

• Other Noteworthy Stuff
  • The open source geocoder w:en:Nominatim used by the OpenStreetMap project is participating in the Google Summer of Code with an internship working on integrating Wikidata as a ranking metric for its search results. Check the development blog.

• Did you know?
  • Newest properties:
    • General datatypes: musical bar, epigraph (literature), copyright exemption, significant place
    • External identifiers: München Wiki article ID, Poincaré Papers person ID, Acharts.co album ID, NOTAM (FAA), CHESNO politician ID, Rollerstory.net skater ID, Nauka Ukrainy scientist ID, OhRanger.com ID, Wynk artist ID
  • New property proposals to review:
    • General datatypes: legend for number, does not have effect, word stem type, Voting system, Class, Peer-review-process properties for journals, Wikisource-Kategorie, line(s), Election called by, image or photo-making technique
    • External identifiers: FGrHist ID, Acharts.co song ID, shmup.com ID, TA2 ID, Hacker News User ID, Swedish lighthouses, EPW author ID, Gaana.com album ID, Cinestaan film ID, Cinestaan person ID, Service d'Information sur les Etudes et les Professions job ID, IBP 4-letter bird species alpha code, PLIA ID, Planespotters.net ID, Awards & Winners artist ID, TuneIn artist ID, AccuRadio artist ID, Jango artist ID, LiveXLive artist ID, mora artist ID, CD Universe artist ID, Ex Libris author ID, Fishpond.co.nz author ID, YesAsia author ID, Supraphonline artist ID, Image-Line artist ID, RMF FM artist ID, eska.pl topic ID, Register nehnuteľných NKP, deejay.de artist ID, Bandsintown artist ID, musica.com artist ID, GreatSong artist ID, AZLyrics.com artist ID, RauteMusik artist ID, Getty Images topic ID, Tunefind artist ID, SoundHound artist ID, SongMeanings artist ID, Census of India ID, OpenWeatherMap city ID
  • Query examples:
    • Bands whose name is part of Tolkien's legendarium (source)
    • Map of offshore windfarms (source)
    • Cities having more Wikipedia sitelinks than their country (source)

• Development
  • Fix a caching problem on termbox (phab:T228978)
  • Investigate options for termbox load testing (phab:T229790)
  • Use thumbnail preferences for thumbnail of Commons media file (phab:T224189)
  • Add tags parameter to Wikibase APIs that edit entities (phab:T229917)
  • Move "Data item" link outside of sidebar toolbox (phab:T66315)
  • Create Maintenance Script to Remove Terms in a Language from Current Revision (phab:T222606)
  • Fix Grafana Datamodel References dashboard (phab:T214894)
  • Add editing widget/input on Bridge (phab:T226998)

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

• Monthly Tasks
  • Add labels, in your own language(s), for the new properties listed above.
  • Comment on property proposals: all open proposals
  • Suggested and open tasks!
  • Contribute to a Showcase item.
  • Help translate or proofread the interface and documentation pages, in your own language!
  • Help merge identical items across Wikimedia projects.
  • Help write the next summary!

Read the full report · Unsubscribe · Lea Lacroix (WMDE) 2019年8月12日 (一) 14:33 (UTC)

Wikidata weekly summary #378

Here's your quick overview of what has been happening around Wikidata over the last week.

• Discussions
  • New request for comments: Improved instructions for translation admin

• Events
  • Current: Wikimania in Stockholm and hackathon, August 14 to 18. Check out the list of all Wikidata-related events. Each session page should include notes, slides and streaming if available.

• Tool of the week
  • In this new section, you can share your favourite tool with the other Wikidata users. You can add some suggestions here.
  • NameGuzzler allows you to automatically add an identical label or alias into many languages (for example, the name of a person or a place). You can define your own custom list of languages that you want to add.

• Other Noteworthy Stuff
  • There is now a Wikiquote page for Wikidata
  • ISA is a new tool to easily add structured data to Commons files, including from mobile
  • You can help improve the vandalism detection by completing a set of labels for ORES
  • QuickStatements won the Coolest Tool Award, category "editor", during the first ceremony at Wikimania 2019
  • New Wikidata-related projects developed during the Wikimania hackathon:
    • Documentation translation sprint: several people translated Wikidata help pages in their own language. Feel free to continue the efforts to make Wikidata more accessible!
    • Item creation helpers helps create similar items, and link them together, with a simple form. Example with skating competitions

• Did you know?
  • Newest properties:
    • General datatypes: manner of inhumane treatment, cases consolidated, typically sells, noun class, does not have effect, substitute director/manager, school class
    • External identifiers: Empik author ID, WP Muzyka artist ID, Interia Muzyka artist ID, The Top Tens ID, merlin.pl author ID, Plus Music artist ID, Kinsky–Halm Catalogue, Raptekster.dk ID, Acharts.co song ID, FGrHist ID, register of real estate NKP, Hacker News User ID, shmup.com ID, TA2 ID, Gaana.com album ID, XING profile ID, Cinestaan film ID, Cinestaan person ID, job ID in Service d'Information sur les Etudes et les Professions, Planespotters.net aircraft ID, PLIA ID, IBP 4-letter bird species alpha code, EPW author ID
  • New property proposals to review:
    • General datatypes: graph radius, Belgian Species List ID, amino acid (start, end) position, ordeal by, protected region scheme, image revision-id, region within image, access restriction status, georeferencing data, number of processor threads, part number, CPUID, based on tabular data, Siddham script name, Number of active electronic terminals
    • External identifiers: OpenWeatherMap city ID, Scribd Publication ID, moly.hu azonosító, Hungarian Movie Database film ID, Lyrics007 artist ID, jog.fm artist ID, Hype Machine artist ID, Liber Liber author ID, Dizionario biografico dei Friulani ID, Just Hear It artist ID, Lyrics Translations artist ID, LINE BLOG user ID, Digitalt Museum ID, MTV UK artist ID, MTV Germany artist ID, MTV Polska artist ID, Vox FM artist ID, Allcinema person ID, Eiga.com person ID, Eiga.com movie ID, GoodRx, BEACON ID
  • Query examples:
    • Books in Bengali Wikisource that are validated (source)
    • Flightless birds of New Zealand (source)
    • Islands in Germany (source)
    • Clandestine center of detention and torture in Chile, Uruguay, and Argentina (source)
    • Same-sex married couples where neither partner has a sexual orientation (source)
  • Schema examples:
    • Danish numerals
    • Danish hyphenation

• Development
  • Fix an issue with the pop up of Wikidata Tours (phab:T223999)
  • Call WikibaseLexeme API with baserevid parameter from the UI (phab:T217245)
  • Fix a bug with CheckConstraintsJob (phab:T227450)
  • Fix a bug with wbgetentities when getting Lexeme subentities (phab:T223995)
  • Add editing widget/input to client edit modal: (phab:T226998)
  • Add tags parameter to Wikibase APIs that edit entities: (phab:T229917)
  • More work on the the production Termbox service
  • tidying up our browser test suite (phab:T229910)
  • adding browser tests for basic editing (phab:T230187)

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

• Monthly Tasks
  • Add labels, in your own language(s), for the new properties listed above.
  • Comment on property proposals: all open proposals
  • Suggested and open tasks!
  • Contribute to a Showcase item.
  • Help translate or proofread the interface and documentation pages, in your own language!
  • Help merge identical items across Wikimedia projects.
  • Help write the next summary!

Read the full report · Unsubscribe · Lea Lacroix (WMDE) 2019年8月18日 (日) 16:50 (UTC)

方針

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

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

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

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

--春卷柯南編輯數突破二萬 ( 論功行賞·刻石留名 ) 2019年4月19日 (五) 08:29 (UTC)

早期長串討論

• 個人認為頁面存廢討論的應該使用{{vfd}}或新建其他模板，ex：Draft:Template:Merge_to-- Sunny00217   2019年4月19日 (五) 14:40 (UTC)
  • 能否{{VFD}}加一个参数？然后使得其显示为这个模板并且加入分类--及时雨 ^留言 2019年4月19日 (五) 14:55 (UTC)
    • 技術上可行，基本上只要在{{vfd}}加入以下參數：“merge|合併|合并=Merge to”，並把Draft:Template:Merge to移動至Template命名空間即可，但還是要Twinkle配合，以及微調機器人設定。Σανμοσα ^{y=0 regardless the value of x} 2019年4月19日 (五) 15:06 (UTC)
    • 在此邀請Xiplus參與討論。Σανμοσα ^{y=0 regardless the value of x} 2019年4月19日 (五) 15:06 (UTC)
• 其實為什麼要將合併請求提交到存廢討論……這豈不增加存廢討論積壓？如果確實需要社群參與，還不如提案到互助客棧條目探討區。--J.Wong 2019年4月20日 (六) 05:40 (UTC)
  • 因為合併請求已經廢止了。Σανμοσα ^{y=0 regardless the value of x} 2019年4月20日 (六) 07:16 (UTC)
    • 之前的原因好像是合併請求效率過低，聊勝於無，合併到AFD可以方便處理。--春卷柯南編輯數突破二萬 ( 論功行賞·刻石留名 ) 2019年4月20日 (六) 10:43 (UTC)
    • 但存廢討論不是這樣用呀……存廢討論應該專注於討論頁面是否需要刪除。缺人處理不是合併理由……如果情況確實複雜，應該提到條目探討區。--J.Wong 2019年4月20日 (六) 11:11 (UTC)
      • 效率低的不是特定页面，而是合并这个动作本身。把合并处理移到PFD不会让合并变得更高效，只会让PFD变得效率低下。 --达师 - 370 - 608 2019年4月20日 (六) 13:09 (UTC)
      • 認同達師君，而且合併請求亦不應該過於依賴管理員處理。--J.Wong 2019年4月20日 (六) 13:18 (UTC)
      • 但是这样不就需要推翻之前的共识，不妥吧？--Cohaf(talk) 2019年4月20日 (六) 14:24 (UTC)
      • 共識會改變，沒什麼不妥。而且之前討論亦不周，沒考慮到效率低之真正原因，只是見到有積壓，然後就想辦法把積壓從這裡掃到另一處。個人不相信這樣就能解決合併積壓。這個合併根本就奇奇怪怪，治標不治本，還有點自欺欺人。--J.Wong 2019年4月21日 (日) 00:38 (UTC)
        • 推翻共识没有不妥，毕竟共识会随着时间改变，但是推翻仅1个月经过投票取得的共识略不妥，以及AFD也处理了1个月而已。现在没人说问题解决了，回应下方，但是只是为了模版问题需要调整其它方针，所以建议做调整，其余就运行多一些时间才调整在我看来没有不妥之处。@Wong128hk：。--Cohaf(talk) 2019年4月21日 (日) 06:12 (UTC)
      • 隨隨便便翻一翻Wikipedia:頁面存廢討論/積壓討論都能見到不少合併請求積壓超過一個月。所以問題解決了？--J.Wong 2019年4月21日 (日) 00:49 (UTC)
        • 集中讨论反而能暴露一些问题，就是合并请求没有管理员处理而已。--悔晚齋（臆語） 2019年4月21日 (日) 05:09 (UTC)
        • 合併過程中其實甚少需要動用管理員權限，所以說回來是為什麼要管理員處理？所以問題是沒有人關注及處理，而不是沒有管理員處理。--J.Wong 2019年4月21日 (日) 05:39 (UTC)
          • 类似历史合并，移动至有一些编辑数量的重定向(需要G8)等？--Cohaf(talk) 2019年4月21日 (日) 06:15 (UTC)
          • 其實歷史合併是移動請求，關於合併歷史的請求，其頁面歷史合併技術上是以時間排序，故如若2頁面時間部相鄰合併起來時間混亂，合併起來就會像是破壞一樣。 Willy1018（留言） 2019年4月21日 (日) 06:19 (UTC)
          • Willy1018君所言甚是。歷史合併完其實比沒合併還差，整個歷史沿革就會斷開，然後就會喪失意義。最後看上去就是messy。--J.Wong 2019年4月21日 (日) 06:35 (UTC)
            • 非常同意。我有见过效果。我这里只是说有可能使用管理员权限的部分，非全部合并都需要历史合并，这个是确定的事情。我也当然了解。--Cohaf(talk) 2019年4月21日 (日) 06:46 (UTC)
  • 參閱過討論存檔12號及14號，雖參與者不少，但問題在從沒考慮過效率差是因為合併過程及討論本身就可以非常費時，亦非一鍵解決，當中變數其多，牽涉很多編輯技巧及判斷。有些條目亦需要熟習相關領域的編者才能決定。本站有海量條目掛有模板，標示有問題需要解決，而合併請求與之其實無異。唯一分別就是合併請求有專頁羅列。如此合併只是將積壓由一處掃往另一處，而根本無法根治問題。跟因為見到某問題標示模板有很多鏈入，而決定刪去模板一樣，根本在自欺欺人，掩耳盜鈴。如此決定根本思慮不周，亦令資訊不再集中。就算真的有有心人想協助解決合併積壓，亦難以協助，還要花時間於存廢積壓中將請求逐頁逐頁找。如此，問題只會更為嚴重。上述14號討論僅僅維持四日，亦未有明確通知，有否發過公告？有否公示？如此推翻決定，請問會有何不妥之處？--J.Wong 2019年4月21日 (日) 07:16 (UTC)
  • 然後就是如此合併會打亂程序。原本存廢討論應該就是討論頁面應否刪除，偶然會有條目可能其實毋須刪除而轉為以合併解決，但第一目標仍然應該在討論頁面應否刪除。如果合併請求亦提案至存廢討論，如此一來，存廢覆核是否需要去處理這些合併請求覆核？但這些頁面本來就不會經存廢討論合併，不是那種臨界條目。如此一來，不是增加了存廢討論及存廢覆核負擔麼？存廢覆核亦非覆核編輯決定之所。又，其實合併請求應該承接存廢討論、存廢覆核之條目合併請求。亦應該提供場地供社群行使合併權力，《關注度指引》就明訂就算條目有來源符合段二要求，社群仍可藉討論達成共識以合併條目。存廢討論及存廢覆核可以決定條目是否有關注度。但既然存廢討論及存廢覆核已經決定條目是否有關注度。就沒道理又在存廢討論及存廢覆核繼續打轉，去決定條目是否合併，而應該移師合併請求或者互助客棧條目探討區。而且如此合併亦會嚇壞新人或者不諳程序者，存廢討論及存廢覆核還是應該單純一點，只處理及討論應否刪除條目。其餘編輯判斷，請另覓他處進行討論。--J.Wong 2019年4月21日 (日) 07:44 (UTC)
• 感谢Wong128hk的说明，可以请执行这个编辑的Willy1018解释为何没有公示就改？以及附送说明关闭的Sanmosa，请看看以上并且回应。感激。--Cohaf(talk) 2019年4月21日 (日) 07:48 (UTC)
  • 已有進行公示，請見公告欄存檔。 Willy1018（留言） 2019年4月21日 (日) 08:47 (UTC)
  • 在下只找到「[公告] 合併請求依據先前討論已經關閉。2019年02月05日, 星期二 (2個月16日前), 12:47 pm (UTC+8)」，是這個麼？但在實行之前，有沒有公告過？在相關討論串表明公示開始？--J.Wong 2019年4月21日 (日) 09:09 (UTC)
    • 是的，請見WT:合併請求#鉴于Wikipedia:合并请求和Wikipedia:移动请求的使用率不高，现发起社群调查、Wikipedia_talk:合并请求#WP:合并请求与存废讨论之{{合并}}、WT:合并请求#合并条目，這三個討論共識均是關閉該計畫。 Willy1018（留言） 2019年4月22日 (一) 13:38 (UTC)
      • 多次討論又或者多次計劃不代表思慮周詳，亦不代表已經處理弊端。當中，[[Wikipedia_talk:合并请求#WP:合并请求与存废讨论之(±)合併|二○一七年四月討論]]，AT君就曾經說過︰「個人認為結論是合併的話，應以轉介的認識交給合併請求重新處理，就如關注度一樣。」只可惜未有進一步論述。--J.Wong 2019年4月28日 (日) 13:24 (UTC)
• 若要調整合併請求的處理方式，不要在存廢討論中進行，現有存廢討論中的合併請求是否可以仍依舊方式進行？（我在2019年1月在Wikipedia:合并请求/存档/2019年提出將注意力不足過動症的非藥物治療合併到注意力不足過動症的治療，後來改到存廢討論中進行，我因故延至3/4才在Wikipedia:頁面存廢討論/記錄/2019/03/04提出合併討論，目前尚未通過 囧rz...，若又要更動處理方式，我怕又要再等一段時間了）。--Wolfch (留言) 2019年4月21日 (日) 14:14 (UTC)
• 已發至存廢討論者就繼續在存廢討論處理吧。--J.Wong 2019年4月21日 (日) 16:38 (UTC)

善後討論

• @Wong128hk：那現在要怎麼處理這個問題？稍後再議？User:春卷柯南、User:Willy1018、User:悔晚斋、User:Cohaf和User: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)
            • 我根本沒說過整合合併請求和頁面存廢討論能夠增加效率。Σανμοσα^{以有涯隨無涯，殆已！} 2019年5月19日 (日) 09:19 (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)
  • @Wong128hk、Shizhao、春卷柯南、Hat600、@Willy1018、悔晚斋、Cohaf、94rain、Sunny00217。Σανμοσα^{以有涯隨無涯，殆已！} 2019年5月22日 (三) 08:57 (UTC)
    • User:Sanmosa可否建草稿好了解一下？（能夠在AFD頁面中提示編者只有在未能自行合併或合併有爭議的情況下才提交合併請求至AFD）-- Sunny00217 - 2019年5月22日 (三) 10:30 (UTC)
      • User:Sunny00217其實只是頁首加一句「只有在未能自行合併或合併有爭議的情況下，才提交合併請求至此，否則應當自行進行合併動作」而已。Σανμοσα 2019年5月22日 (三) 12:56 (UTC)
    • 其实我觉得Wong128hk的方式才是正途。毕竟这个是否要删除页面，性质完全不一样。而且合并和拆分经常需要对条目主题有一定了解的才比较好处理。共识是合并了，但是没人知道怎么把具体内容合并起来，那就是长期积压在AFD了，倒不如列在一个专门页面更容易慢慢来做更为稳妥--百無一用是書生 (☎) 2019年5月22日 (三) 11:39 (UTC)
      • User:Shizhao所以才說是暫行辦法；現在上面的討論有些混亂，整個討論的焦點完全變了。Σανμοσα 2019年5月22日 (三) 12:53 (UTC)
        • 上面到底在討論什麼？沒細看還以為是一個月前的討論被拿出來鞭屍 :P —— Eric Liu _{坐等萬次編輯（留言．留名．學生會）} 2019年5月22日 (三) 13:18 (UTC)
          • 現在整個討論的主題變了重開合併請求與否。User:Ericliu1912Σανμοσα 2019年5月23日 (四) 10:24 (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)
      • 翻閱以往討論，一直都未有具體改善方案，往往只是拋出問題，此乃乏人回應原因。斷不可以此作為證據支持「社群已對此抱持負面態度」之說。既然如此，連同Jimmy版本一起改就可以了。然後，請勿再次迴避問題，請交出合併理據。個人記得之前有人討論指出「合併請求」乏人問津，以致長期積壓。一段長時間後，條目依舊模樣。請問合併後，此問題是否已經得到妥善解決？--J.Wong 2019年5月31日 (五) 09:37 (UTC)
        • 當時提案把合併請求併入AFD的原因並不是長期積壓，而是為方便統一集中處理各類刪併，我不認為糾纏於這個偽命題有任何意思。我究竟強調過多少次了，增加效率並不是當時提案將兩者合併的原因！Σανμοσα 2019年5月31日 (五) 10:21 (UTC)
      • 閣下及社群必先要面對現實，承認合併可以是極複雜決定，程序亦繁複，難以一蹴而就。不然此問題永遠沒法解決。--J.Wong 2019年5月31日 (五) 09:42 (UTC)
      • 所以在下上面是否已經問了「為方便？那請問有沒有試過要求技術帝幫忙支援合併請求？又有沒有試過改善合併流程？」？既然閣下確認當初是為了方便故。那請解決為方便故而產生之一系列問題。不能一句方便，然後明知有問題都視而不見。這不是什麼偽命題。是確確切切存在之問題。請正視及解決。--J.Wong 2019年6月1日 (六) 02:30 (UTC)
      • 「方便統一集中處理」，這也是支持取消合併之理據呀。要從各存廢討論頁面中找出合併請求，也非常不便。閣下可有想過？為方便而產生其他不便。--J.Wong 2019年6月1日 (六) 02:33 (UTC)
• @Wong128hk：如果有其他明確支持兩者再分立的意見，我不反對再分立，所以我個人建議多找一些人進來討論（現在你我二人對答都是隔幾天隔幾天這樣回應，其他人像啞子一樣）。另外，我還有一件事希望請你幫忙，我會在你的用戶討論頁詳細說明。Σανμοσα 2019年6月1日 (六) 07:38 (UTC)
  • 上面書生還不夠明確？--J.Wong 2019年6月1日 (六) 07:47 (UTC)
    • 我的意思是用不用再向其他成員參與過討論的人再確認一下？Σανμοσα 2019年6月1日 (六) 08:00 (UTC)
    • 請便。--J.Wong 2019年6月1日 (六) 12:05 (UTC)
• @春卷柯南、Sunny00217、94rain、hat600、Cohaf、@悔晚斋、Willy1018、Wolfch：現就此諮詢各位是否同意合併請求和頁面存廢討論再分立。Σανμοσα 2019年6月1日 (六) 13:13 (UTC)
  • 我比較贊成將合併請求整合到頁面存廢討論中--Wolfch (留言) 2019年6月1日 (六) 13:40 (UTC)
  • (＝)中立，本身就極少在管合併討論，不做決定User:Wong128hk和User:Sanmosa-- Sunny00217 - 2019年6月1日 (六) 13:42 (UTC)
  • 支持合併討論，長期合併請求僅有少數人維護。 Willy1018（留言） 2019年6月1日 (六) 14:05 (UTC)
• User:Wong128hk這樣的情況，我豈不是很尷尬……至少有二人反對分立。Σανμοσα 2019年6月1日 (六) 15:01 (UTC)
• Wolfch君，請多說一點，說一下理據。Willy1018君，難道現在存廢討論不是只有少數人維護？合併後，還增加了他們負擔，把原本不用他們處理的合併請求都推到他們身上，於心何忍呀？而且之前社群一直沒有正視問題，提供足夠指引，令致合併請求缺人參與，缺乏系統，缺人關注。而且合併請求歸到存廢討論，那分拆討論又要放到哪裡？存廢覆核嗎？於理不合呀。--J.Wong 2019年6月2日 (日) 01:05 (UTC)
  • 增加負擔？afd沒有明確共識就用無共識，可以合併無法自行處理使用允許合併，拆分討論放到條目討論頁或條目探討。 Willy1018（留言） 2019年6月2日 (日) 01:15 (UTC)
  • 原本就不是全部合併請求都交到存廢討論，現在把全部合併請求交到存廢討論，當然是增加負擔。而且《刪除方針》規定存廢討論最長討論時長時五週。合併討論可以非常複雜，超過五週，個人覺得根本不為過。所以什麼是允許合併，由誰去合併？為什麼會出現「允許合併」，明顯就是管理員或者存廢討論結案者不欲參與合併過程，所以這樣不是強人所難是什麼？--J.Wong 2019年6月2日 (日) 01:22 (UTC)
  • 所以為什麼合併請求不能在「條目討論頁或條目探討」進行？--J.Wong 2019年6月2日 (日) 01:23 (UTC)
  • 我有參與合併請求，不過不常參與。建議合併到存廢討論的原因是：合併請求的討論有些會在合併請求中進行，有些會在條目討論頁，但參與討論的人似乎比較少，若放在存廢討論，比較會有多一些人參與討論。而且有時存廢討論的結果也可能是條目的合併，若是合併請求和存廢討論分開，存廢討論後可能還需要一次的合併請求，需要多討論一次。--Wolfch (留言) 2019年6月2日 (日) 06:04 (UTC)
    • 首先，個人非常明白主張合併原因之一就是合併請求乏人問津。這點，可以改善，合併至存廢討論並非唯一解決辦法。當初缺乏指引及系統是合併請求乏人問津原因之一。用戶無從得知申請是否已經獲得通過。漸漸就會失去耐性及離之而去。正如上面在下建議，在下很希望分拆之後，合併請求能有系統地處理申請，例如將申請分為三類。如需討論則訂下討論期限。尋求TW支援。以至適度增加合併請求曝光率，例如第三類，特別複雜個案則可按需同時遞交至互助客棧條目探討區，或者於公告欄作出告示。閣下既有參與合併請求，在下非常想與閣下詳談此等方案。但前提是合併請求從存廢討論獨立出來，始能制訂適切改革方案，及度身訂造合身制度。另一點，在下希望指出是，無錯的確存廢討論有時會得出合併決定，但不應因此就將全部合併請求都撥入存廢討論。如果情況簡單，存廢討論得出合併決定後，就應該付諸實行，而毋須合併請求再次討論。但相反，如果情況複雜，存廢討論議決合併就會成為方向。合併請求則應接續討論相關合併細節。又若然存廢討論結案者並不熟悉條目，未知應該如何合併，其實於判定合併以後，尚應備案至合併請求，甚或條目探討區或相應專題。合併請求尚應處理複雜合併，如長條目甲可能一部分適合合併到條目乙，一部分適合合併到條目丙。此等討論並不適合，亦不應該出現於存廢討論。存廢討論結果應有適度約束力，現在合併決定多數適用於關注度不足條目。因為有約束力，所以一般要推翻合併決，需要經存廢覆核審核。在下雖然這陣子比較少出沒於存廢覆核，然而在下亦非常憂慮因為存廢討論承接全部合併請求，而令存廢覆核要承接全部合併請求覆核。如此，並不合理。--J.Wong 2019年6月2日 (日) 08:49 (UTC)
• 現正式就重新拆分《合併請求》及《存廢討論》交付公示，為期七日，如無合理異議，則視為通過。--J.Wong 2019年6月9日 (日) 04:28 (UTC)
  • @Wong128hk：在公示什么，我看上方讨论和议题，多是（“現就此諮詢各位”部分）支持整合两者。个人反对目前拆分，社群没有精力和需求维护两个地方。--YFdyh000（留言） 2019年6月9日 (日) 08:08 (UTC)
  • 存廢討論同樣沒有資源處理整合後的大量工作量，而且如此根本破壞制度。如果閣下反對分拆，請回應在下上方論點。而非單單拋出如此理據。--J.Wong 2019年6月9日 (日) 08:39 (UTC)
  • 另外，既然沒資源維護，請也回答「所以為什麼合併請求不能在「條目討論頁或條目探討」進行？」，為什麼非存廢討論不可？存廢討論結案者既然使用「允許合併」去過關了事，為什麼閣下會覺得這樣就叫處理了？個人對此方案很多疑惑，既然YFdyh000君支持整合，請為在下解惑。在下上面就已經詳細分析了此次整合有何壞處，請亦鉅細無遺地為大家分析整合後有何好處，解決了什麼問題，最好做個數據比對。就例如上面閣下說了「社群没有精力和需求维护两个地方」，請問是否有數據支持此說？--J.Wong 2019年6月9日 (日) 08:51 (UTC)
  • @Wong128hk：共识可以改变，“破壞制度”的制度也非定局。上方其他人提出了反对分拆的意见，未见共识改变和简明易懂的理据，最多是无共识而维持现状，即不分拆。「所以為什麼合併請求不能在「條目討論頁或條目探討」進行？」，因为惯例，大家比较习惯放在存废讨论处理（包括投票版式、时间索引、关闭讨论等）与积压、乃至过期，正如存废讨论也会积压。放在条目探讨是过期存档的命运，讨论页则更是关注寥寥。如果有人持续处理合并请求，并提出意见希望分拆，个人认为比较可靠，否则没坏别修。有一个点子，将合并请求作为一个索引页，链向各个存废讨论，如果开始有人跟进并展现出效率，再议拆分。如果想法是将没人处理的合并请求放到更没人理的地方，个人反对。--YFdyh000（留言） 2019年6月9日 (日) 10:54 (UTC)
  • 沒壞別修，應該是維持分拆，而非維持整合。慣例並非將全部合併請求都拋到存廢討論，所以現在是沒有足夠理據下強行改變社群習慣。個人亦希望提出方案修訂合併制度，但個人覺得前提是確立共識分拆。最多就是不立即執行，但必須先確立此共識。--J.Wong 2019年6月9日 (日) 11:14 (UTC)
  • 翻查《合併請求》2019年存檔，又不是沒人持續處理。在下上面亦說過，要增加曝光，方法有很多。存廢覆核前身是刪除檢討，以前也是門可羅雀，現在呢？由按年存檔，到按季存檔，到現在按月存檔。本站條目數量破百萬，有什麼可能沒有足夠合併需求支撐起一個獨立申請頁……--J.Wong 2019年6月9日 (日) 11:18 (UTC)
• 反对强行通过这一案的提议。在下以为，上方的所有讨论清晰的表明了如下两点：
  1. 参与讨论的绝大多数参与者反对该项提议或表示中立；且，
  2. 支持该提议的用户没有强有力的证据来完全驳倒上述反对者，全凭借自身主观感受来判断并不合理。

  另外，在下建议相关支持者以清晰有条理的方式撰写相关理由，否则会给人一种茹太素的既视感。--悔晚齋（臆語） 2019年6月9日 (日) 11:30 (UTC)

  • 我都沒有說要強推⋯⋯我提出這個建議是因為現況是合併請求導流到頁面存廢討論，不過配套工作沒有做好（比如社群不認為{{Mergeto}}是合法的AFD模板，結果我建議合併的時候，在條目上方掛了一個Mergeto模板，人家就說請求無效，予以否決，到後來掛了VFD才沒有人阻止），這是客觀事實而不是主觀臆測。要解決這個問題就兩個辦法，要麼就完全整合，要麼就分家。不過後來王爺爺提出反建議（重設合併請求），而且得到不少人的同意，那就順應一下好了。--春卷柯南編輯數突破二萬 ( 論功行賞·刻石留名 ) 2019年6月9日 (日) 11:44 (UTC)

作為經常處理afd的管理員，我覺得還是將合併、分拆等遷出afd比較妥當。本身允許併入就是權宜之計，而合併和分拆也只是afd的其中一個結案選項而已，換言之如果本來就是提議合併、分拆的話，置於同一頁面整合起來比較清楚。而且，將併拆置於afd內，就算結案是允許併入，到最後是否真的併入好，要跟進起來非常困難，如果有專門頁面的話，相信會比較容易跟進。—AT 2019年6月9日 (日) 12:14 (UTC)

如果要在存废讨论处理合并事宜，那么请先确定哪种类型的合并应该放到存废讨论，还是所有的合并都放到存废讨论？{{Mergeto}}类模板本来就是挂上模板等人合并用的，而不是提删用的。另外，在存废讨论处理的话，共识是合并，但很久都无人合并应该如何处理？毕竟合并很耗费时间和精力，甚至不少条目的合并还需要一定的专业知识才合并得了。那么如何处理这种问题？一直在存废讨论积压下去？--百無一用是書生 (☎) 2019年6月10日 (一) 02:09 (UTC)

• 大家這樣僵持下去並不能解決任何問題，倒不如先採取我之前提出的暫行辦法：在{{vfd}}加入「merge|合併|合并=Vfd-mergeto」參數，把Draft:Template:Vfd-mergeto移動至Template命名空間，並在頁面存廢討論頁首加入一句「只有在未能自行合併或合併或有爭議的情況下，才提交合併請求至此，否則應當自行進行合併動作」提示編者。至於是否分立應該另開討論處理，否則一直這樣下去沒共識只會造成冗長討論。Σανμοσα 2019年6月11日 (二) 04:08 (UTC)

我觉得将改挂{{Merge}}作为结案选项、作为提报的首选步骤（当原页面内容不急需删除——不处在活跃编辑、非错误名称）为好。对于无需讨论只需合并处理的页面，不建议挂到请求页。--YFdyh000（留言） 2019年6月12日 (三) 13:27 (UTC)

{{Merge}}提报？那么无需讨论只需合并的页面，由于时间精力有限或者知识不足等原因无法合并的怎么处理？放在那里不管也不挂模板？--百無一用是書生 (☎) 2019年6月13日 (四) 02:11 (UTC)

User:Shizhao就是改挂Merge模板并结案啊，放在Category:需要合併的條目而非存废讨论/合并请求页面中积压，等有兴趣查阅、修缮有关条目的人处置。无共识的合并同上，继续在相关条目中编辑、条目讨论页中讨论。--YFdyh000（留言） 2019年6月13日 (四) 03:22 (UTC)

• 剛提了editprotected，相信很快就能夠完成最後的整合功夫，那樣頁面存廢討論和合併請求就算是暫時完成整合了。至於是否正式再分立，我建議應該另外開新討論。Σανμοσα 2019年6月13日 (四) 03:16 (UTC)
• 一、本末倒置，為什麼寧願存廢討論沒法處理就隨他在分類中積壓，都不確確切切，踏踏實實解決之前合併請求沒系統處理申請而衍生之問題。如果積壓到頭來能在條目討論頁解決，為什麼不一開始就在條目討論頁中解決？
• 二、既然上面都說了此併整未完全完成，而在未完全完成之前，已經有數個用戶提出合理質疑，為什麼暫行方案不是退回到整合之前，而是繼續整合？閣下有什麼理由會覺得在下會接受？更遑論該次整合連公示都沒有，就隨隨便便整合。如此重大決定，為什麼不用公示？
• 以上。--J.Wong 2019年6月15日 (六) 00:42 (UTC)
  • 其实整合的工作早已完成，正確來說這個暂行辦法只是为免部分人以為放在同一頁的合併请求是刪除请求而已，不做也無大礙。Σανμοσα 2019年6月15日 (六) 05:34 (UTC)
  • 所以有多本末倒置才需要這樣。所以不是說了，存廢討論是處理刪除請求之地，很多新人及用戶未必對這有這麼多了解，一見到要去存廢討論不是給嚇倒，就是如閣下所言，混亂非常。如此混亂，根本不是單單轉個模板就完事。現在又變成了「整合工作早已完成」了啦？但閣下還是沒答為什麼如此重大決定不用公示？--J.Wong 2019年6月16日 (日) 02:31 (UTC)
    • 因為你們這樣僵持落去只會沒有共識、一事無成。Σανμοσα 2019年6月16日 (日) 09:58 (UTC)
    • 問題會不會是此次整合根本沒有完成整個程序，現在亦已有反對聲音，根本就不應該繼續下去。更沒可能容許所謂暫行辦法。--J.Wong 2019年6月23日 (日) 12:46 (UTC)
    • 這裡要討論是「是否整合」，而非「是否繼續整合」。在下已將相關未公示編輯回退。--J.Wong 2019年6月23日 (日) 12:51 (UTC)
    • @Wong128hk：完全整合，或完全回復到整合前？-- Sunny00217 - 2019年6月26日 (三) 08:53 (UTC)
    • @Wong128hk？—— Eric Liu_{（留言．留名．學生會）} 2019年7月2日 (二) 05:26 (UTC)
    • ？--J.Wong 2019年7月7日 (日) 08:25 (UTC)

• (？)疑問@Sanmosa、Wong128hk、YFdyh000、Shizhao：所以這個討論變相2個禮拜都沒有人回應也叫「公示」 囧rz...?　會否有爭議存在（等等再不用機器人就存檔了）?--Z7504非常建議必要時多關注評選（留言） 2019年7月21日 (日) 10:36 (UTC)
  • 個人覺得更大爭議在之前整合討論未曾公示就整合。現在只是恢復該次未公示編輯而已。--J.Wong 2019年7月21日 (日) 10:47 (UTC)
  • 不管整合还是恢复，重点是要有人处理。如果哪位有意致力于此，请发表意见，或许更有价值。个人坚持之前的意见，在没有足够的参与者和流程共识前，分立会更加积压、小众化而废弃。--YFdyh000（留言） 2019年7月21日 (日) 11:51 (UTC)
  • 還是那句，沒道理在存廢討論及存廢覆核常駐管理員有異議情況下將積壓就這樣掃往存廢討論及存廢覆核。--J.Wong 2019年7月21日 (日) 12:09 (UTC)
  • 要解決問題又不是只有一個方法，為什麼硬要併入存廢討論？--J.Wong 2019年7月21日 (日) 12:16 (UTC)
  • 不希望合并入存废讨论。但目前的合并流程需要改进，绝大部分讨论无人参与，无人结案，因此不得已推到存废讨论，也不是不能理解。~ viztor ✪ 2019年7月21日 (日) 12:34 (UTC)
• (？)疑問那「合併請求」是否考慮重定向?　只有兩種：一就是恢復「合併請求」頁面，並取消存廢討論使用合併請求這功能。二就是現在這個提案。--Z7504非常建議必要時多關注評選（留言） 2019年7月21日 (日) 13:15 (UTC)
  • 個人不認為只有這兩個方案。個人建議參照關注度討論做法，先將問題列出，再訂立目標，逐點擊破。而不是一二三就跳到結論，然後強迫社群接受。--J.Wong 2019年7月21日 (日) 13:38 (UTC)

目前存废积压已经900多了。合并问题并入存废只能是使存废的积压情况变得更为严重而已--百無一用是書生 (☎) 2019年7月23日 (二) 12:54 (UTC)

所以明明有人反對，什麼叫de facto合併？--J.Wong 2019年8月12日 (一) 12:03 (UTC)

那事實上是處於合并狀態，確實是de facto合併沒錯。산모사 ^DC17_{GAN FLN1 FLN2} 2019年8月12日 (一) 15:34 (UTC)

如果是次討論要結束，個人相信只有一個結論，就是︰整合是重大決定，理應按慣例先行公示，而之前未有公示，今次討論又遇有合理異議，故而維持原來分立狀態。如仍認為需要整合，應當重新討論。--J.Wong 2019年8月12日 (一) 12:12 (UTC)

我認為閣下現在是為求達到自己的目的而刻意製造冗長討論。閣下的觀點其實也被部分用戶反對，依理應該維持現狀（可以無共識狀態結案），而現狀就是de facto合併。산모사 ^DC17_{GAN FLN1 FLN2} 2019年8月12日 (一) 15:34 (UTC)

閣下如果堅持不給維持現狀結案的話，我會考慮采取進一步行動。산모사 ^DC17_{GAN FLN1 FLN2} 2019年8月12日 (一) 15:37 (UTC)

我不认为现在de facto是合併，事实是以前什么样基本还是什么样。有提交删除的，有直接挂合并模板并讨论页留言的--百無一用是書生 (☎) 2019年8月13日 (二) 01:56 (UTC)

Sanmosa君，請回應書生所言。在下意見與書生完全一致。--J.Wong 2019年8月13日 (二) 05:56 (UTC)

但基本上請求還是送去AFD，迴避{{vfd}} template≠不是de facto合併。書生只説了事實的一半。산모사 ^DC17_{GAN FLN1 FLN2} 2019年8月13日 (二) 06:01 (UTC)

而且我也表示了不反對無共識狀態結案，我的重點是Wong128hk你是不是仍然堅持製造冗長討論。先close這裏的討論好嗎，已經沒人有精力參與這討論了。산모사 ^DC17_{GAN FLN1 FLN2} 2019年8月13日 (二) 06:05 (UTC)

其實如果閣下之前結論不是那個，而是「整合是重大決定，理應按慣例先行公示，而之前未有公示，今次討論遇有合理異議，亦未有共識，故而維持原來分立狀態。如仍認為需要整合，應當重新討論。」在下亦不會重啟此討論。上面在下已經說了，那應該提醒相關用戶，而非將錯就錯。--J.Wong 2019年8月13日 (二) 06:22 (UTC)

User:Wong128hk不同意閣下這樣的結案理由。要這麽説的話，其實合併請求和頁面存廢討論現在是介乎整合與分立之間，分立狀態并不是討論開始時“原來的狀態”。我建議直接只說“維持現狀”。산모사 ^DC17_{GAN FLN1 FLN2} 2019年8月13日 (二) 06:41 (UTC)

其實在下上面也已經說了，如非一開始就認為需要刪除，又或者不是因為關注度問題，其實就不應該提交到存廢討論。一直以來都是這樣，沒有變過。至於TW，稍後修改合併程序後，亦應該一併修改。TW提刪頁面不應該再提供合併選項。該選項無疑加劇誤解。存廢討論至所以有合併選項作為結案理由，只是為了滿足《刪除方針》「刪除乃最後手段」此項大原則。如一開始已覺得合併就可以解決問題，為什麼要提刪？--J.Wong 2019年8月13日 (二) 18:08 (UTC)

閣下或者應該看看「合併請求」，兩個新請求，證明「合併請求」根本並非無人關注。就不明為什麼硬要整合到存廢討論，加劇存廢討論積壓，又加重存廢覆核負擔。此動作無疑甚為無理，亦不切實際。--J.Wong 2019年8月13日 (二) 18:17 (UTC)

這兩個用戶不能作準。Gianthard的編輯始於今年3月，編輯次數50次也沒有，我認為他是不清楚實況才會在那裏提報；而查Kannoflower的貢獻紀錄，他並不關注客棧的討論。再者，管理員Xiplus在1月把頁面中的{{historical}}模板移除，造成這樣的誤解在所難免。另外，我個人並不認為存廢討論／存廢覆核積壓、負擔是一個問題（反正該結案的討論，你們大多都還不結案處理，那我多放若干請求進去其實也沒分別）。合併請求之所以要併入頁面存廢討論，是因為這樣這些請求才能得到更高的關注，基本上以前合併請求的關注率都比較低，並且有機會扼殺了部分意見（例如主張不應合併而應保留條目，或主張不應合併而應刪除相關內容者）。我不認為維基百科的制度是用來優待管理員的，談存廢討論積壓／存廢覆核負擔於我而言沒有甚麼意義，如何令合併請求得到更高的關注是我唯一在意的地方。산모사 ^DC17_{FLN1 FLN2} 2019年8月14日 (三) 00:33 (UTC)

我剛才看看，我突然發現原來Wong128hk你是想故意迴避我的statement。「合併請求和頁面存廢討論現在是介乎整合與分立之間」這個statement，究竟你是否同意？산모사 ^DC17_{FLN1 FLN2} 2019年8月14日 (三) 00:45 (UTC)

一、沒什麼能不能作準。維基百科不是只開放予熟練程序之人。該等請求都是八月才提出，與一月是否掛有模板又有何干？

二、閣下說法非常不負責任，亦是無端指責。管理員亦只是義工，什麼叫「反正該結案的討論，你們大多都還不結案處理，那我多放若干請求進去其實也沒分別」？又什麼是「我不認為維基百科的制度是用來優待管理員的」？這那裡優待了？閣下不斷放大一個問題，然後又置另一個問題於不顧。個人實在不見得如此於維基百科有何益處，亦不見得討論下去會有何結果。甚至有擾亂之虞︰因為不滿管理員該結案而不結案，做成存廢討論積壓，於是明知會加劇存廢討論積壓，繼續強推，而示不滿。

三、不認同。兩者分立無誤。

四、在下必須嚴正指出︰要令「合併請求」獲得關注，整合至存廢討論並非唯一方法，而且整合亦非上上之策。閣下執意整合，及堅持所謂「合併請求和頁面存廢討論現在是介乎整合與分立之間」，正正障礙「合併請求」改革，令流程無法改善及得到更多關注。

以上。--J.Wong 2019年8月19日 (一) 20:13 (UTC)

我這裏只是為上面針對你的反對意見說話而已，要不然開個投票吧。산모사 ^DC17_{FLN1 FLN2} 2019年8月20日 (二) 23:47 (UTC)

規範簽名可用的HTML/XML Tag

前言

近期簽名出現擴展HTML/XML Tag，或使用LaTeX以及LaTeX宏包的簽名，例如<score></score>，形如

被部分編者指出不當，但我認為可以被解釋成妥當，屬於模糊地帶，為了避免爭議

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

• 因為以下的原因，請不要在簽名中使用圖片：
  • 耗費更多的系統資源；
  • 減少可搜尋性，並且使從頁面複製文字更加困難；
  • 從實際資訊中潛在地轉移注意；
  • 在多數瀏覽器中，圖片不能隨文字縮放，會使該行比其他沒有使用圖片的高。
• 建議對「加入由擴展功能提供的HTML/XML Tag（Help:HTML#解析器扩展标签）的簽名」進行管制。
  • 根據Help:HTML#解析器扩展标签和Special:版本，目前中文維基會呼叫到擴展的HTML/XML Tag有：

• <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>、
• （已禁止，指引連結WP:SIG#TLCSS）、
• <mapframe></mapframe>、
• <maplink></maplink>、
• <quiz></quiz>、
• <ref></ref>、
• <references/>（Self-Closing Tag）、
• <syntaxhighlight></syntaxhighlight>、
• <source></source>、
• <timeline></timeline>

• 已禁止的HTML/XML Tag（見Wikipedia:签名#外观的規定）：

• <big></big>
• <br/>
• <center></center>
• <hr/>

• 建議禁止的其他HTML/XML Tag：

• <div></div>

• 以上，建議對「含有由擴展功能提供的HTML/XML Tag的簽名」進行管制。 歡迎討論，副知游魂--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月25日 (六) 17:49 (UTC)
• nowiki和div的禁止理由？其他没意见，似乎无需求。以资源为由禁用nowiki，不赞同。--YFdyh000（留言） 2019年5月26日 (日) 02:48 (UTC)
  • (：)回應我沒有說要禁止nowiki啊，@YFdyh000：--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月26日 (日) 04:40 (UTC)
    • User:A2569875我以为您提案“會呼叫到擴展的HTML/XML Tag”全部禁止。所以“进行管制”有无具体想法，以及究竟增加多少资源消耗。--YFdyh000（留言） 2019年5月26日 (日) 06:32 (UTC)
      • @YFdyh000：所以我是開放討論啊，因為也不確定哪些該禁止，我建議禁止的是<gallery></gallery>、<pre></pre>（會產生不明斷行）、--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月26日 (日) 10:42 (UTC)
        • (！)意見@Sunny00217：(※)注意我根本就沒有漏簽名，原本的留言修定版本54562319，原本的留言是跟下面表格一起，簽名在表格下方，是你後來一直擅自更改、亂加章節段落把他切開在來說我沒簽名，這樣不對吧。我在討論頁我有詢問你編輯我的發言的理由是啥，您還沒回應。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月1日 (一) 05:50 (UTC)
          • @A2569875：閣下說我改到閣下的留言這件事，抱歉，忘記這件事了，個人覺得還是留在客棧就好，不要引用；至於簽名被切開這件事，閣下在這個版本中在留言裡加入章節，但極少數留言會在中間加入章節根本沒看過，未翻查歷史紀錄而誤會，抱歉-- Sunny00217 - 2019年7月1日 (一) 10:35 (UTC)

個別HTML/XML Tag 簽名示例

• 沒有使用任何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)

  我是留言 -- 2019年5月26日 (日) 10:28 (UTC)

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

---

• <imagemap></imagemap>簽名效果：

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

  我是留言 --

  

  

  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)

  我是留言 --${\frac {\sqrt {2}}{2}}$ 2019年5月26日 (日) 10:28 (UTC)

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

---

• <ce></ce>簽名效果：

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

  我是留言 --${\ce {H_2O}}$ 2019年5月26日 (日) 10:28 (UTC)

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

---

• <chem></chem>簽名效果：

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

  我是留言 --${\ce {CO_{2}{+}H_{2}O\rightleftharpoons H_{2}CO_{3}}}$ 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)

  我是留言 --

  

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

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

---

• <source></source>簽名效果：

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

  我是留言 --簽名

  <a href="/wiki/User:Example" title="User:Example">Example</a>
  

  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)

  我是留言 --簽名 2019年5月26日 (日) 10:28 (UTC)

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

参考資料

---

• <references />簽名效果：

  有參考文獻的討論blablabla。

  正常的留言 --正常的簽名 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)

  我是留言 --簽名

  <a href="/wiki/Wikipedia:互助客栈/方针" title="Wikipedia:互助客栈/方针"><del>User:Example</del></a><root><template><title>kidding</title></template></root>
  

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

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

---

• <timeline></timeline>簽名效果：

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

  我是留言 --

  

  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)

---

• <indicator></indicator>簽名效果：

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

  我是留言 --簽名<indicator name="signtest">跑到頁頂的文字</indicator> 2019年5月26日 (日) 10:28 (UTC)

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

参考資料

討論區

• 所以我是開放討論啊，因為也不確定哪些該禁止，我建議禁止的是
  1. 明顯是包含圖像，已有方針禁止：<gallery></gallery>、<imagemap></imagemap>、<imagemap></imagemap>
  2. 會產生不明斷行，影響排版：<pre></pre>、<categorytree></categorytree>、<hiero></hiero>、<inputbox></inputbox>、<poem></poem>、<source></source>、<syntaxhighlight></syntaxhighlight>、<timeline></timeline>、<div></div>、<p></p>
  3. 嚴重影響排版：<inputbox></inputbox>、<quiz></quiz>
  4. 技術原因須禁止：<indicator></indicator>（會跑到頁頂）、<ref></ref>（影響參註運作）、<references/>（影響參註運作）、<section></section>（擾亂AFD積壓標記）、<templatedata>（干擾templatedata運作）、<noinclude></noinclude>、<includeonly></includeonly>、<onlyinclude></onlyinclude>、<section></section>（干擾部分要將討論嵌入他頁的運作）

  以上歡迎討論。如果@YFdyh000：問較具體的意見，就是這些了--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月26日 (日) 10:42 (UTC)

  • (～)補充，對於<math></math>（數學）、<score></score>（樂譜）、<ce></ce>、<chem></chem>（化學）等 可能需要討論。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月26日 (日) 10:48 (UTC)
  • 感谢列明。除了nowiki和div，其他禁止我都不反对，很多有明显副作用或不适用签名区。因为您提到“建议禁止的其他HTML/XML Tag：”，我才疑惑为何禁止某几项。上文提到的需要讨论的几种，如果对版式、分类和数据没有明确影响，从调用资源角度来禁用的证据可能不够充分。--YFdyh000（留言） 2019年5月26日 (日) 10:54 (UTC)
    • (：)回應@YFdyh000：自己看<pre></pre>、<categorytree></categorytree>、<hiero></hiero>、<inputbox></inputbox>、<poem></poem>、<source></source>、<syntaxhighlight></syntaxhighlight>、<timeline></timeline>、<div></div>、<p></p>等會有甚麼效果，會使簽名出現斷行，影響排版，依據Wikipedia:签名#外观，應禁止。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月26日 (日) 17:39 (UTC)
      • <div></div>簽名效果：

        我是留言 --

        簽名

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

      • 這樣最好是可以。我覺得不行。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月26日 (日) 17:43 (UTC)
• (＋)支持：可討論。MeritTim 2019年5月26日 (日) 18:47 (UTC)
  • (？)疑問：@MeritTim：請問你的{{Support}}是指哪個部分？--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月26日 (日) 18:57 (UTC)
    • 支持設立規範。MeritTim 2019年5月26日 (日) 18:58 (UTC)
  • div：？？？？？
    --Br₂ 2019年8月21日 (三) 02:35 (UTC)

簽名中使用LaTeX

• (！)意見LaTeX 相關 HTML/XMLTags在參數設定上可以設定成沒有圖片的樣式，例如Special:参数设置#mw-prefsection-rendering中有一個「LaTeX 原始碼」選項，因此部分位於WP:簽名#外觀中的部分理據是站不住腳的，因此說「使用了圖片」我覺得不妥，因為那不是「圖片」而是「LaTeX」。此外，我補充一點，直接複製該區域會獲得LaTeX原始碼。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月26日 (日) 19:15 (UTC)
• (：)回應：感谢关注。我对HTML和XML不怎么了解，但决定用这个签名之前肯定也是一句句对过方针指引的。我说一下我稍微懂一点的地方，不懂就不说了。当然说的也很可能错，还望诸位海涵。当然不想涵也可以不涵。

1. 系统资源：我在沙盒试的时候，这一个签名差不多一百字节。
2. 第二条：不懂，不说。
3. 转移注意：其实说实话，要不是之前（应该）没人用过这个，乐谱当签名，这比五颜六色大红大紫的艺术字不显眼多了，为此我还特地采访了我的三位室友，他们对这句实话表示了肯定。
4. 会使这行更高：1.5倍行高。换完签名以后我一直用手机做小编辑，感觉没什么大区别。蓝桌型签名似乎也是1.5倍行高，往下翻就有，正下方的话题讨论。实际上这签名在我参数设置里的显示是前后各空一行，就是乐谱自己必须占一行。这肯定不行啊，本来想换的，结果早上起来忘了这事，在dykc投票时候，惊喜地发现在设置外面它是不空行的。天上掉黑猫一样的愉悦。

个人态度，(＋)支持讨论一个统一标准，(－)反对逼我换签名。在没有明确的方针指引论述讨论共识要求我换签名的时候以明显不符合规范为理由要求我换签名是明显不符合规范的。在大管理员习加同志以明显不符合规范的理由要求我换签名的明显不符合规范的留言底下再复读一遍以明显不符合规范为理由的明显不符合规范的要求当然也是明显不符合规范的。

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₂NKC） 2019年5月27日 (一) 05:25 (UTC)

(？)疑問U:YFdyh000有甚麼看法？--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年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)

• (！)意見我覺得這種簽名可以接受。因為它並不會像<hiero></hiero>斷到隔壁行，能維持在同一行內，認為在可容忍範圍內（言下之意是提議禁止<hiero></hiero>形式的古埃及文簽名），有鑑於上面User:YFdyh000所言以“指引”来一刀切“禁止”，会过于严格，我表示認同，對Xi+強制要求User:游魂換簽名一行為表示抗議，並提出(？)異議。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月27日 (一) 09:58 (UTC)

• 現行指引內已有不建議使用big或font-size影響行高度的規定，難道score沒有影響行高度嗎？--Xiplus#Talk 2019年5月27日 (一) 10:59 (UTC)
  • 聰明，沒有從我的LaTeX以及LaTeX宏包與一般圖片性質不同論下手。是的，影響行高這點我倒是沒話說，但我仍然要再次強調，不要迫害LaTeX。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月27日 (一) 15:52 (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₂NKC） 2019年5月27日 (一) 15:44 (UTC)

• 我認為Xiplus在Topic:V0eniuqnlalrne89的解讀完全沒問題，如此的簽名在現行規制下是不可接受的（圖片+在部分browser明顯高於平均行高），游魂在這種情況下確實是理當更改簽名的；不過我也(＋)支持在以後開許控制在某一行距內的圖片簽名（開設例外，希望游魂也能看看怎樣把行高fix得全面些）。另外，我(＋)支持為HTML/XML Tag作出進一步規範管制。Σανμοσα 2019年5月27日 (一) 15:05 (UTC)
  • (：)回應：圖片只是LaTeX的一種渲染形式，所謂禁用圖片是禁用指向一個已上傳之圖像的位置，因為圖像可以被重複上傳，會造成已存檔的簽名發生改變，而LaTeX具有Static Data的特性，當然我也可以立刻去phab提一個「將LaTeX渲染到<canvas></canvas>」的提案，先不論通過與否，我都完全反對並(！)抗议「LaTeX一概視為圖像」論。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月27日 (一) 15:24 (UTC)
    • (～)補充：當然，行距/行高問題，這點我確實無法反駁，啞口無言。非常抱歉游魂我這點可能幫不了您了。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月27日 (一) 15:28 (UTC)
      • LaTeX對於非註冊用戶和註冊用戶的預設情況下都是渲染成圖片，不明白為何要無視這個事實，堅持說不是圖片？另外圖片被禁止的理由有4個，屏除掉系統資源的其他三個，LaTeX應該都是通通符合（第二點，確實可以複製，但不能搜尋，這樣就沒辦法在瀏覽情況下根據簽名搜尋留言）。--Xiplus#Talk 2019年5月27日 (一) 15:57 (UTC)

        (：)回應根據U:YFdyh000的言論，有幾點他認為不符合。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月27日 (一) 16:04 (UTC)

        • (：)回應：@Xiplus：我認為只要「確保簽名存檔後不會因為其他頁面被改動而造成簽名出現變化」、「確保簽名位於同一行」、「不干擾排版」、「行高夠矮」、「別人看了不會不舒服」我們就不應迫害，或禁用。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月27日 (一) 16:00 (UTC)
          • 我從最一開始就是提出行高問題。--Xiplus#Talk 2019年5月27日 (一) 16:07 (UTC)
            • (：)回應：既然這樣，行高的部分LaTeX也不合你的論述。LaTeX是一種排版語言，行高當然也是可以調整的，例如${\begin{smallmatrix}{\frac {\sqrt {2}}{2}}\end{smallmatrix}}$（數理）、
              
              （樂理）、${\begin{smallmatrix}CO_{2}{+}H_{2}O\rightleftharpoons H_{2}CO_{3}\end{smallmatrix}}$（化學）。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月27日 (一) 16:21 (UTC)
              • 那不就好了嗎？--Xiplus#Talk 2019年5月27日 (一) 16:53 (UTC)
            • 關於您提到的「不能搜尋」的部分，我認為可以添加如下規定「如需要在簽名中使用LaTeX，請確保你的簽名有包含非LaTeX的部分，以利在瀏覽情況下根據簽名搜尋留言。」如何？--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月27日 (一) 17:01 (UTC)
              • 就此提议发现，我之前对“减少可搜索性，并且使从页面复制文本更加困难；”的理解是搜索引擎（MediaWiki内置和外置如Google）和页面上复制（Ctrl+C），但你们理解的可搜索性是“Ctrl+F”吗。--YFdyh000（留言） 2019年5月27日 (一) 18:32 (UTC)

              • 为什么需要对签名内容进行搜寻，只要能搜到用户名或相应的用户名关键词即可。--Leiem（签名·留言） 2019年5月28日 (二) 02:08 (UTC)

              • (：)回應：請看示例：

• (＆)建議：喵喵喵我是藪貓。-- 瑪莉歐RIP
  
  2019年5月27日 (一) 19:27 (UTC)
  • (！)意見：我可以解離成碳酸根跟氫正離子哦。-- 我喝碳酸${\ce {CO_{2}{+}H_{2}O\rightleftharpoons H_{2}CO_{3}}}$ 2019年5月27日 (一) 19:27 (UTC)
    • (：)回應：嗯吶啊，我是娜娜奇，好棒喔，樓上上簽名可以用「瑪莉歐RIP」搜索；樓上可以用「我喝碳酸」搜索。 -- User:娜娜奇 2019年5月27日 (一) 19:27 (UTC)

• 我認為有補充非LaTeX內容助於搜索就足夠了。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月27日 (一) 19:27 (UTC)

• Re YFdyh000：原文是「they can reduce searchability and make it more difficult to copy text from a page」。--Xiplus#Talk 2019年5月28日 (二) 00:09 (UTC)

• @Leiem：为了找出特定命名空间/页面下的发言，如果MediaWiki搜索引擎能识别和找出链接目标，那么链接文本无用似乎就问题不大。但当前似乎是找不到的，如搜索游魂 prefix:Wikipedia:互助客栈不能找到他的留言，此时签名文本的有效与独特性就很有必要。
• 仍然不懂是Find in page还是Search on site。--YFdyh000（留言） 2019年5月28日 (二) 18:50 (UTC)

• 行高问题肯定存在，但差距并不明显，我不觉得需要在没有明确危害的前提下依指引严格要求和禁止。且该例并没有扰乱指引举例的“文字”排版（如高低错落或折行），指引也未明确约定行高限制为200%，加之当前此处没有共识。禁用图片的目的上方有讨论过了，渲染结果为图片比较难说符合指引立意之图片（如File:）。@Xiplus：，系统资源层面也是符合的，扩展渲染成图片和网络传输给用户。搜索问题，很多人的签名文本也是很难找到原主人的（尤其是依外观找出本来用户名），这在目前还是一个常见问题，轻微转移注意力同上。缩放问题，暂未见到抱怨，如有应考虑，但也要注意，很多人的签名以及众多页面、模板也并没有良好的网页亲和力，单就此例禁止也许吹毛求疵。如果游魂能将乐谱缩小些（技术是否不支持？）、追加一些文字和链接（哪怕如🎵），应该更为大家所接受。上方宇帆提出的用例很不错，字号12下的“
  
  ”高度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:魔術字則不在此限。 必須確保在篇幅允許的情況下簽名能在同一行顯示，換句話說您的簽名除了因篇幅因素造成的換行效果外，不能有其他的換行現象出現。 例如，這樣是可以接受的 留言內容留言內容留言內容留言內容留言內容。 --User:Example （討論） 2019年5月29日 (三) 19:13 (UTC) 但不能出現像下方的簽名 留言內容留言內容留言內容留言內容留言內容。 -- User:Example （討論） 2019年5月29日 (三) 19:13 (UTC) 您的簽名必須出現至少一個不是由擴展標籤渲染出的部分，例如使用LaTeX必須至少在簽名中加入一個或多個非LaTeX字符或其他純文字。 這是因為若簽名完全由擴展標籤渲染，則將會減少可搜尋性，並且使從頁面複製文字更加困難 您的簽名不能干擾其他行的排版，比如不能出現置左、置中或置右等元素。 此外，由於技術原因，您不應在簽名中使用下列HTHL/XML標籤： <ref></ref>、<references/>（影響參註運作） <noinclude></noinclude>、<includeonly></includeonly>、<onlyinclude></onlyinclude>、<section></section>（干擾部分要將討論嵌入他頁的運作） <templatedata>（干擾templatedata運作） 长度

• 以上，歡迎討論@YFdyh000、MeritTim、游魂、SH6188：@Xiplus、Leiem、Sanmosa：--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月29日 (三) 19:13 (UTC)
  • 没问题，虽然有点长。只是“目前并未禁止在签名中使用LaTeX或其他由扩展标签生成的非文字渲染结果”，让人想尝试其他扩展标签了呢。InputBox、ImageMap等扩展标签，估计也会干扰讨论及用户界面。去除我划线的部分为好，未逐一讨论的标签，用常识/视作无共识。--YFdyh000（留言） 2019年5月30日 (四) 00:28 (UTC)
  • 没问题。--Leiem（签名·留言） 2019年5月30日 (四) 01:45 (UTC)
    • @YFdyh000：我改成了「使用與LaTeX相關擴展標籤生成的非文字渲染結果」，因為技術上LaTeX本來就無法直接使用，必定是需要透過擴展標籤來實現。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月30日 (四) 07:44 (UTC)
      • (：)回應：@YFdyh000：在提議的規範中「必須確保在篇幅允許的情況下簽名能在同一行顯示」就已經能駁回<inputbox></inputbox>的使用（由於<quiz></quiz>和<inputbox></inputbox>等有輸入框的網頁元素通常都會太高或換行至隔壁行）、提議的規範中「您的簽名不能隱含包含任何來自File:名字空間的內容」亦能駁回<imagemap></imagemap>的使用。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月30日 (四) 08:06 (UTC)
        • 這樣（122%）應該是不會太高吧？--Xiplus#Talk 2019年5月30日 (四) 09:05 (UTC)
          • @Xiplus：那加入「簽名中不能加入讓使用者輸入訊息的互動式內容，包括但不限於輸入框、核取方塊或下拉式清單等」，如何？--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月30日 (四) 09:30 (UTC)
            • 我認為不需要特別去限制形如--
              2019年5月30日 (四) 09:35 (UTC)
            • 這樣的簽名。通常這類被抵制的理由是「轉移注意」，但我相信真的想把它塞進簽名的用戶會盡可能去調整。剩下的部分可透過「處理問題簽名」方針來解決。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月30日 (四) 09:49 (UTC)
              • 由於這個小節已經近一周無人提出新的意見，我就視為對於「目前並未禁止在簽名中使用與LaTeX相關擴展標籤生成的非文字渲染結果」有達成初步共識，(！)意見但對於原句「目前并未禁止在签名中使用LaTeX或其他由扩展标签生成的非文字渲染结果」，由於我認為其他附加規範/附加條件就足以限制了，我想問問@YFdyh000：目前對原句的想法。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年6月8日 (六) 19:32 (UTC)
                • User:A2569875没什么想法，“或其他由扩展标签生成的非文字渲染结果”我认为尚缺乏讨论共识与实例，以及还不需要明文与细则来规范。--YFdyh000（留言） 2019年6月8日 (六) 20:00 (UTC)
    • 另外，说一下之前的规范，似乎使用<big></big>并不会超过两倍行高。--Leiem（签名·留言） 2019年5月30日 (四) 01:47 (UTC)
      • 同意，使用單個big（114%）應該是在可接受範圍，三個big為150%。--Xiplus#Talk 2019年5月30日 (四) 01:55 (UTC)
  • 除了{{!}}以外的魔術字為何不替換引用來使用？--Xiplus#Talk 2019年5月30日 (四) 01:55 (UTC)
    • (：)回應目前沒有人使用，且大部分若使用也可以根據提議的規範中「簽名結果必須是靜態的」來駁回使用，至於是否替換引用認為用常識/視作無共識即可。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月30日 (四) 08:29 (UTC)
      • 哪些是靜態的，請舉例幾個？--Xiplus#Talk 2019年5月30日 (四) 09:25 (UTC)
        • 可能是{{!}}（|）、{{ns:2}}（User）、{{#tag:math|2+2}}（$2+2$）等不管怎樣都不會變的魔術字，像是這種{{REVISIONUSER}}（Xiplus）或{{#expr:{{CURRENTHOUR}}+8}}（16）就不行，因為肯定會變來變去。高開銷的魔術字也不行。這種不允許的魔術字才要替換引用。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月30日 (四) 09:42 (UTC)
          • 此處的靜態（static）是相對於dynamic，（或許應使用const？）--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月30日 (四) 09:55 (UTC)
            • 雖然幾乎不可能發生，但是{{ns:2}}的輸出結果是可以改的，這仍然被認為是靜態的？--Xiplus#Talk 2019年5月30日 (四) 11:35 (UTC)
            • 為何不允許高開銷？--Xiplus#Talk 2019年5月30日 (四) 11:35 (UTC)
              • (：)回應：@Xiplus：如果一個用戶簽名有高開銷的魔術字，又沒有替換引用，那他簽名了幾百次，討論頁不就壞掉了？ 如果您是指有人改了namespace id，那麼namespace name{{ns:User}}總可以了吧。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月30日 (四) 12:02 (UTC)
                • 我說輸出結果可以改。大量使用同一個高開銷魔術字，計數只會被計為一次，所以不會壞掉。--Xiplus#Talk 2019年5月31日 (五) 11:00 (UTC)
                  • 好吧，另外想請教一下User:Xiplus以技術上，輸出結果不能改的魔術字有哪些？（也就是打上去保存編輯後再也不會改變的）有這種魔術字嗎？--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月31日 (五) 11:03 (UTC)
                    • 應該是只有{{!}}；如果覺得站點名稱不可能修改，那麼{{SITENAME}}系列也可以考慮進來，同理，不會有人無聊去改命名空間名稱的話，{{ns:2}}也是可以被列入的，這只是機率的問題。--Xiplus#Talk 2019年5月31日 (五) 11:14 (UTC)
• 嘗試在Wikipedia:互助客栈/其他和Special:PermaLink/54629367編輯並預覽（不是直接瀏覽頁面），我可以感受到互助客棧比較快，查看預覽最底下的「剖析器分析資料/實際使用時間」，互助客棧所花時間也是比較少的。--Xiplus#Talk 2019年5月31日 (五) 11:15 (UTC)
  • @YFdyh000、Leiem：--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月31日 (五) 11:19 (UTC)
    • 访问速度没问题。--Leiem（签名·留言） 2019年5月31日 (五) 11:22 (UTC)
      • 我認為在社群有出現些「應放寬圖像」的意見，因此我認為這些不需要在意，正如U:YFdyh000所言。但考量到File:圖像有「可透過他頁編輯發生變化」的特性，因此我認為File:圖像是不能開放，不管系統資源佔的多大多小，因為這意味著簽名可在存檔後透過更改或重新上傳File:圖像改變，当用户离开计划，无人管理的這類签名亦会成为破坏的目标，因此怎樣都不能放寬。因此要聽取這些社群有出現些「應放寬圖像」的意見的方式就是這個折衷方案，僅要能確保存檔後簽名不會因為其他外在因素出現顯著的內容變化，就不應用各種形態迫害這類簽名，若是不想看到這些簽名，大可以啟用強制顯示預設簽名的小工具，不必干涉他人選擇簽名的自由。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年6月2日 (日) 10:06 (UTC)
        • User:A2569875以前一直以為強制顯示預設簽名的小工具只作用於自己的簽名，沒想到竟然也包含別人的。大開眼界啦。—— Eric Liu _{編輯次數突破一萬（留言．留名．學生會）} 2019年6月2日 (日) 12:38 (UTC)
          • (：)回應 WP:強制顯示使用者預設簽名 --宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年6月2日 (日) 13:03 (UTC)
            • 由於這個小節已經近一周無人提出新的意見，我就視為有達成初步共識。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年6月8日 (六) 19:27 (UTC)
• (！)意見 既然 big 都被禁止，行高 200% 還是太高了吧，會讓這個簽名太過搶眼。設置在120%左右如何？ -- Vakrieger♀️🏳️‍🌈 << (TALK💢❤️🗯️) 2019年6月4日 (二) 13:42 (UTC)
  • 我只反对无谓的比别人大，导致不美观。过于严格的限定，那还不如禁止个性化签名了（就像WP:Flow）；签名源码美观度也各异；以及是否还要不能太小，不能太长，不能太花；以及讨论语句的排版、留白。用常识和共识就好，尚不需要明文标尺。--YFdyh000（留言） 2019年6月4日 (二) 14:06 (UTC)
    • 由於這個小節已經近一周無人提出新的意見，我就視為有達成初步共識：不須明文限制行高的數值，透過「行高不要太高」、常識、以及「處理問題簽名」來解決此問題。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年6月16日 (日) 07:48 (UTC)
      • 所以「[[User:Example2|Example2]]<div style="display:none"><mapframe text="Downtown [[wikipedia:San Francisco|San Francisco]]" width=250 height=250 zoom=13 latitude=37.8013 longitude=-122.3988 /></div>」顯示為「Example2
        」的簽名可被接受。--Xiplus#Talk 2019年6月20日 (四) 01:46 (UTC)
        • 想問問User:YFdyh000和U:Leiem的意見。--娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年6月20日 (四) 06:50 (UTC)
        • 我觉得这基于常识不能接受，只有负面价值，浪费服务器和用户资源。如果隐藏（不可见）内容有任何艺术价值（如ASCII艺术），倒可以考虑。--YFdyh000（留言） 2019年6月20日 (四) 06:56 (UTC)
        • 同上，除非有艺术价值。--Leiem（签名·留言） 2019年6月20日 (四) 13:03 (UTC)
• 我认为没必要进行行高、大小、各种HTML标签等细节限制。厘清一个总体思想即可。说影响服务器资源，倒是给个比如使用魔术字和不使用魔术字对服务器产生页面的速度比较，这样才令人信服。至于显示效果，有个人觉得两倍行高可以，有的人看1.5倍已经生气气了，见仁见智。--Gqqnb（留言） 2019年6月25日 (二) 02:26 (UTC)
  • (：)回應Gqqnb，我現在想推行的主要不是说影响服务器资源，而是「編輯他頁會不會影響已存檔簽名」，例如在簽名中加入Help:圖像，透過重新上傳File:圖像，就可以把已存檔的簽名搞掉。正如現行禁用模板和Help:模板樣式的規範條文所言：「而且，當使用者離開計劃，無人管理的簽名模板亦會成為破壞的目標。」，因此進一步地考慮禁用部分Help:魔術字，避免掉「會隨時間變化的簽名」，目的是要確保討論存檔後內容不再改變，以免「當使用者離開計劃，無人管理的簽名成為破壞的目標。」。而下方的「避免隱藏內容」是一個臨時動議，因為用戶可能透過「塞入變動內容於隱藏區域」繞過「確保簽名儲存編輯後就不會再發生變化」的規定。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年6月30日 (日) 08:51 (UTC)
    • 再看看還有沒有其他意見。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月7日 (日) 10:16 (UTC)
      • 由於這個小節已經近一周無人提出新的意見，我就視為有達成初步共識。有異議請盡速提出。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月12日 (五) 16:20 (UTC)

关于隐藏内容

• 提議規範「簽名不應包含不必要的隱藏內容」@Leiem、YFdyh000、Xiplus：。--娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年6月20日 (四) 13:33 (UTC)
  • (＝)中立，先看看其他人的讨论。--Leiem（签名·留言） 2019年6月20日 (四) 13:38 (UTC)
  • 何謂「不必要的」？--Xiplus#Talk 2019年6月20日 (四) 13:53 (UTC)
    • 例如您上面舉的例子，一張地圖放簽名，而且還看不到，令人匪夷所思，顯然沒有必要，既然本來就不給看，那就不清楚放入的「必要」性何在了。其可由「WP:常識」判斷。--娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年6月20日 (四) 20:30 (UTC)
      • User:A2569875任何人都沒有義務解釋簽名的設計理念，我基於我的設計理念放入這個隱藏內容，那麼我認為這就是有必要的；如果理由是「不必要」而產生這條規定，那麼我反對。--Xiplus#Talk 2019年6月20日 (四) 23:19 (UTC)
        • @Xiplus：如果您沒有意見我就提議不對你上方給出的大型隱藏內容類簽名做出規範。或者加入「簽名不建議包含隱藏內容，若造成其他使用者反感，其他使用者可以要求移除指定的隱藏內容」。--娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年6月22日 (六) 08:21 (UTC)
          • @A2569875：我對於是否加入條文都無意見，但試問若有人覺得反感但簽名主人拒絕配合修改該如何處理？--Xiplus#Talk 2019年6月22日 (六) 09:13 (UTC)
            • @Xiplus：WP:签名#處置問題簽名：妥善地與使用者溝通、與使用者協調、尋找合適的解決方案。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年6月24日 (一) 08:59 (UTC)
              • User:A2569875簽名本人可以強烈主張不會令人反感，是否令人反感無法客觀證明。--Xiplus#Talk 2019年6月24日 (一) 09:12 (UTC)
  • (＝)中立。浪费资源可基于常识。担心这个条款被任意解读、无共识，如编辑源码时可见的隐藏的“请大家支持xxx”“最喜欢xxx了”“I love xxx”“维基休假中”等能否客观判别。--YFdyh000（留言） 2019年6月20日 (四) 21:01 (UTC)
• 條文改成

  「簽名不應包含不必要、不當或沒有藝術價值的隱藏內容，例如编辑源码时可见的隐藏的“请大家支持xxx”、“最喜欢xxx了”、“I love xxx”、“维基休假中”等是可以接受的隱藏內容，而「[[User:Example2|Example2]]<div style="display:none"><mapframe text="Downtown [[wikipedia:San Francisco|San Francisco]]" width=250 height=250 zoom=13 latitude=37.8013 longitude=-122.3988 /></div>」顯示為「Example2

  」則不適當。」

  如何？@YFdyh000、Leiem、Xiplus：。 -- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年6月20日 (四) 21:10 (UTC)

  囧rz...把例子加进去有点羞耻Play……没有例子的话，我不反对，希望未来发生争议时，参考此处讨论，不要将“不必要”的解释扩大化。我反对例子中“维基休假中”以外的隐藏内容，尤其是宣传或拉票性质的，与表达个性化无关。而喜欢/讨厌xxx，有违社群礼仪、包容性，并可能是宣传。--YFdyh000（留言） 2019年6月20日 (四) 21:19 (UTC)

  很多人簽名都有連結到某些頁面的（可接受）宣傳行為，但對於簽名本身是不是「不必要」的？--Xiplus#Talk 2019年6月20日 (四) 23:19 (UTC)

  适当的观点或宣传可以接受。盈利类的可以算不当的。--Leiem（签名·留言） 2019年6月21日 (五) 06:29 (UTC)

• 晚點會整理出一個小結版本。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月20日 (六) 01:13 (UTC)
  • 正在進行公示的準備。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月16日 (五) 07:44 (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 />）。 簽名不建議包含隱藏內容，若造成其他使用者反感，其他使用者可以要求移除指定的隱藏內容，例如不當的觀點或宣傳以及盈利類的內容等。Leiem於2019年6月21日 (五) 06:29 (UTC)意見 HTHL/XML標籤 除了上述規定需要禁止的HTHL/XML標籤（<big></big>、<br/>、<center></center>、<hr/>）以及隱含引入圖像的HTHL/XML標籤（包括但不限於<gallery></gallery>或<imagemap></imagemap>等）之外，並沒有限制對其他HTHL/XML元素的使用。 例如目前並未禁止在簽名中使用與LaTeX相關擴展標籤生成的非文字渲染結果，例如<score></score>或<math></math>等，但必須符合下列規範： 渲染結果的行高不應超過其他行的1.5倍 簽名結果必須是靜態的，也就是說不能因為其他頁面被編輯而發生改變，也不能有隨著日期或時間變化的內容，包含外部連結的影響，也必須確定現在的結果不會因為移動到他頁而發生變化（例如討論串被存檔） 這意味著，您的簽名不能隱含包含任何來自File:名字空間的內容、不能使用<categorytree></categorytree>將分類內容包含入簽名、不能使用模板或模組輸出內容。 簽名中不能加入讓使用者輸入訊息的互動式內容，包括但不限於輸入框、核取方塊或下拉式清單等。 必須確保在篇幅允許的情況下簽名能在同一行顯示，換句話說您的簽名除了因篇幅因素造成的換行效果外，不能有其他的換行現象出現。 例如，這樣是可以接受的 留言內容留言內容留言內容留言內容留言內容。 --User:Example （討論） 2019年5月29日 (三) 19:13 (UTC) 但不能出現像下方的簽名 留言內容留言內容留言內容留言內容留言內容。 -- User:Example （討論） 2019年5月29日 (三) 19:13 (UTC) 您的簽名必須出現至少一個不是由擴展標籤渲染出的部分，例如使用LaTeX必須至少在簽名中加入一個或多個非LaTeX字符或其他純文字。 這是因為若簽名完全由擴展標籤渲染，則將會減少可搜尋性，並且使從頁面複製文字更加困難 您的簽名不能干擾其他行的排版，比如不能出現置左、置中或置右等元素。 此外，由於技術原因，您不應在簽名中使用下列HTHL/XML標籤： <ref></ref>、<references/>（影響參註運作） <noinclude></noinclude>、<includeonly></includeonly>、<onlyinclude></onlyinclude>、<section></section>（干擾部分要將討論嵌入他頁的運作） <templatedata>（干擾templatedata運作） 魔術字 若要在簽名中使用魔術字需要注意下列規則：討論時間戳2019年5月31日 (五) 11:14 (UTC) 若簽名中需要使用魔術字則需要確保您的簽名在對應討論頁保存後內容不再改變。 例如{{SITENAME}}、{{lc:靜態字串}}和{{!}}可以用於簽名 而{{PAGENAME}}（存檔後內容會改變）、{{NUMBEROFARTICLES}}、{{CURRENTYEAR}}（內容會隨時間改變）則不能用於簽名，但可以替換引用來使用。 不得使用控制頁面的顯示方式或其他行為的魔術字，例如__NOTOC__、{{DISPLAYTITLE:標題}}等。 长度

-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月24日 (三) 17:55 (UTC)

• 簡而言之除了行高和style、隱藏內容等就是「編輯他頁會不會影響已存檔簽名」，正如現行禁用模板和Help:模板樣式的規範條文所言：「而且，當使用者離開計劃，無人管理的簽名模板亦會成為破壞的目標。」，因此進一步地考慮禁用部分Help:魔術字，避免掉「會隨時間變化的簽名」，目的是要確保討論存檔後內容不再改變，以免「當使用者離開計劃，無人管理的簽名成為破壞的目標。」。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月24日 (三) 17:58 (UTC)
• (？)疑問 如果我没记错，<section>只是一个标准html元素，请问它有什么干扰嵌入的能力呢？Bluedeck 祝福香港 2019年7月25日 (四) 02:11 (UTC)
  • (：)回應@Bluedeck：，mw:Extension:Labeled_Section_Transclusion，如果簽名有mw:Extension:Labeled_Section_Transclusion，則AFD積壓可能會異常。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月25日 (四) 06:37 (UTC)
    • 原来是只有在用一种特殊的方式使用这个标签的时候才会影响transclusion的作用，如果普通的使用没有关系。不过即便如此，为了避免混乱，全部直接禁止也无妨。Bluedeck 祝福香港 2019年8月1日 (四) 04:11 (UTC)
      • (：)回應，請看

        {{#tag:section|我是一個section}}：效果「」

        <section>我是一個section</section>：效果「」

        不認同您的說法，section根本完全無法使用，其所代表之物根本不是html <section> tag，會直接變成Parser tags在transclusion（<section></section>會直接被mw:Extension:Labeled_Section_Transclusion擴展吃掉，導致最終不會有東西被渲染。）。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月1日 (四) 12:41 (UTC)

        诶呀，试过真的是这样，我刚才没读完文档就想当然了，对不起。既然事实如此，更加有理由禁用它了。我支持。Bluedeck 祝福香港 2019年8月1日 (四) 18:14 (UTC)

        • 好的。 先放個幾天看看有無其他意見，若無就可以等幾天後開始準備公示。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月2日 (五) 12:15 (UTC)
          • 已逾一周無其他意見，視此小節有初步共識。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月9日 (五) 18:49 (UTC)

• 等待一段時間，若無其他異議則可以準備公示。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月9日 (五) 18:49 (UTC)

公示期討論

• 現交付公示，為期一周，到東八區時間2019年8月26日下午六時三分止，若期內無合理異議則修訂條文。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月19日 (一) 10:00 (UTC)
  • (＋)支持新增的那些內容；(＆)建議順便修訂「外觀」第一項，明確禁止<big>和效果相當於<big>的標籤（特別是 CSS font-size 標籤，不得超過100%）。另外，建議明確禁止<div>，因為會導致換行。-- NSW VAK·RKS 💢❤️🗯️ 2019年8月21日 (三) 01:38 (UTC)
    • div：？？？？？
      --Br₂ 2019年8月21日 (三) 02:37 (UTC)
      • @Vakrieger：參見上方討論，因CSS可以防止換行，因此改用條文約束「須確保簽名除因自動排版換行外不應出現斷行」。此外是否限制為100%有反對意見，所以不會去限制相關標籤或語法的使用。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月21日 (三) 03:00 (UTC)
    • @Brror、A2569875： div 是可以用CSS禁止換行，但仍會誤導忽略CSS或者不太聰明的網頁爬蟲和解釋器（比如某些瀏覽器的閱讀模式，和 Pocket、Instapaper 之類的，還有機械人，示例：[1]）。另外，改成 inline 的 div 和 span 又有什麼區別？-- NSW VAK·RKS 💢❤️🗯️ 2019年8月21日 (三) 03:21 (UTC)
    • 關於100%--這是BIG文字、這是120%文字。禁止前者，不禁止後者，好像不太合情理。-- NSW VAK·RKS 💢❤️🗯️ 2019年8月21日 (三) 03:26 (UTC)
      • +1。因原案“应避免采用这些标记”及指引性质，新增的“上述规定需要禁止”有待明晰效力，个人希望所谓“需要禁止”效力不强，应在“请勿添加”与“最好避免”之间，即“请避免”，绝大多数情况下不允许、少数情形依共识例外，未见变为强制性方针的必要。--YFdyh000（留言） 2019年8月21日 (三) 05:23 (UTC)
        • @YFdyh000：現行執行中的條文是「应避免采用这些标记，例如<big>和<span style="font-size:200%;">^{（或者更多）}的标签（这是BIG标签的文本），这样做会扰乱文本的显示方式；」。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月21日 (三) 05:39 (UTC)
      • 「禁止」也好，「建議避免」也好，在下只是認為應該對 big 標籤和超過 100%/1em 的 font-size 標籤一視同仁。若大家認為 150% 大小的簽名可以接受，也應該接受具有一兩個 big 標籤的簽名 -- NSW VAK·RKS 💢❤️🗯️ 2019年8月21日 (三) 06:24 (UTC)
    • @YFdyh000、Leiem：。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月21日 (三) 03:34 (UTC)
    • 无异议。--Leiem（留言·签名·传送门） 2019年8月21日 (三) 04:27 (UTC)
    • 将规则写复杂、变成强制性规定非我的本意。(＝)中立。--YFdyh000（留言） 2019年8月21日 (三) 05:23 (UTC)

新提案：完全重做RDRNC

將RDRNC章節替換為：

中文維基百科允許創建符合重定向方針的非中文重定向。創建者須在重定向頁面放置外文重定向通告模板。

創建者亦須在頁面底部提供證明此重定向外文名的中文可靠來源。

就此條文而言，除一般可靠來源外，以下事實亦可視為可靠來源：

1. 重定向標題與維基數據記錄的目標條目外文標題相同或非常相似，或者
2. 外文維基百科存在相同或非常相似的重定向，指向維基數據跨語言連結的外文對應條目（例如「zh:蘋果」存在跨語言連結"en:Apple"，已有"en:Malus domestica"重定向至"en:Apple"，則「zh:Malus domestica」重定向至「zh:蘋果」符合規定）

重定向目標主題應與重定向的語言有關，或以重定向的語言廣為使用，否則（不允許/不應/不建議）創建。

「外文重定向通告模板」準備是翻譯英文維基百科對應模板。

這個方案主要是參考英文維基百科的作法，那邊已經實行多年，似乎沒有明顯弊端。中文這邊其實也早就有一些Apple，Orange之類的（當然主要是消歧義但性質也差不多），也未見惡劣影響。在下認為此方案方便讀者搜尋之餘，也關注到社群的一些擔憂，不妨一試。-- Vakrieger♀︎ (💢❤️🗯️) 2019年7月10日 (三) 09:59 (UTC)

• User:Vakrieger這個我認為應該移到下面的討論串討論。산모사 ^DC17 2019年7月10日 (三) 14:50 (UTC)
  • User:Sanmosa下面那個討論的是《重定向》的其他部分，不是RDRNC。我不贊成移動，可能讓下面的討論失焦。-- Vakrieger♀︎ (💢❤️🗯️) 2019年7月11日 (四) 05:30 (UTC)
    • User:Vakrieger那我建議另開一個新討論串討論。산모사 ^DC17 2019年7月11日 (四) 05:49 (UTC)
      • 完成-- Vakrieger♀︎ (💢❤️🗯️) 2019年7月12日 (五) 02:28 (UTC)

• 我覺得這個方案能解決巡查、查證困難的問題。如果此案通過，我估計99%的非中文重定向都會落入那兩種情況中。如果社群認為有需要，我可以幫忙編寫一個巡查員機器人。-- Vakrieger♀︎ (💢❤️🗯️) 2019年7月12日 (五) 04:24 (UTC)

@Sunny00217：(！)強烈抗议快速關閉。上面寫好的只是在全文通過前不建立新的重定向，沒說條文在通過前不能討論新的方針（畢竟是暫行方案）。況且，通過全篇《重定向》的討論已在進行，我是想這個議題在下面討論通過後再總結和公示，現在發出只是想拋磚引玉。請第三方定奪此話題是否應該快速關閉。-- Vakrieger♀︎ (💢❤️🗯️) 2019年7月13日 (六) 12:03 (UTC)

以前不怎么来客栈，请问这快速关闭是随便谁都可以关的吗？如果关掉，可以再开吗？这算编辑战吗？

上面的章节，本来是在正常讨论，忽然两个“暂定”方案抛出来，然后又被提案人自己关掉，然后之前的讨论就变成“不活跃”了。这回则是关掉别人开的topic，而且还是“快速关闭”。有没有一定之规啊？

就这章的这个提案本身，我看着好像还不错。--Cswquz（留言） 2019年7月13日 (六) 22:48 (UTC)

这也算是一种提案，没有必要关。~ viztor ✪ 2019年7月14日 (日) 00:04 (UTC)

• 我推翻了關閉；這是永久辦法的可能方案之一。산모사 ^DC17 2019年7月14日 (日) 00:45 (UTC)
• 我認為可以考慮把提議條文和現行RDRNC融合，而非完全取代現行條文。산모사 ^DC17 2019年7月14日 (日) 00:45 (UTC)
• 我建議的新條文如下：

“ 中文維基百科允許創建符合重定向方針的非中文重定向。創建者須在重定向頁面放置非中文重定向通告模板。

創建者亦須在頁面底部提供證明此重定向外文名的中文可靠來源。

就此條文而言，除一般可靠來源外，以下情況亦可視為可靠來源：

1. 重定向標題與維基數據記錄的目標條目外文標題相同或非常相似；
2. 外文維基百科存在相同或非常相似的重定向，指向維基數據跨語言連結的外文對應條目（例如「zh:蘋果」存在跨語言連結"en:Apple"，已有"en:Malus domestica"重定向至"en:Apple"，則「zh:Malus domestica」重定向至「zh:蘋果」符合規定）；或
3. 符合下列「特殊非中文重定向」條件中任何一個的重定向。

重定向目標主題應與重定向的語言有關，或以重定向的語言廣為使用，否則（不允許/不應/不建議）創建。

特殊非中文重定向

1. 學術名稱：科學用語、電腦技術等的專門用語、動植物的學名，這些詞語是字典裡查不到的，例：Homo sapiens→人。
2. 國際性：國際知名的企業、建築等：像Yahoo!→雅虎、McDonald's→麦当劳、Coca-Cola→可口可乐等等。
3. 日語異體字：中文無法完整對應的漢字，或日語獨創的和製漢字。例如像田中理恵→田中理惠、豊臣秀吉→丰臣秀吉等等。
4. 日語假名：コゲどんぼ、駒都えーじ（→駒都英二）因為沒有正式的譯名，導致譯回中文的名字有多個版本等等。
5. 作品：原文名稱知名度遠大於中文譯名者，如Harry Potter→哈利·波特、Final Fantasy→最终幻想系列、The Lord of the Rings→魔戒等。
6. 人名以外的縮寫：常用縮寫，像GMP→良好生产规范。
7. 時區：世界各地的時間UTC+8、GMT+8等等。
8. 化学品CAS号：文献中所记载的每种化合物的唯一编码，如106-98-9→1-丁烯。
9. Emoji符號可以根據Unicode定義的名稱（即Full Emoji List中的CLDR Short Name）建立指向該定義的重定向。若另有其他符合可供查證方針的用途，則應改為建立消歧義頁面。
10. 機場的ICAO代碼，如ZSSS（→上海虹橋國際機場）；但和其他四字縮寫有衝突時，應改為消歧義。
11. 書籍、學術期刊的外文名稱重定向至中文名稱。

”

以上。時區、CAS號、Emoji和ICAO代碼並不合原提案的兩個特殊情況或通用要求，但也理應保留。산모사 ^DC17 2019年7月15日 (一) 09:25 (UTC)

• (＋)支持保留原來的一些豁免條件。在下覺得1、2、3、4、5、6、11明顯已經包含在上面的兩種情況，刪除掉不會有什麼影響；其他的可以保留。-- Vakrieger♀︎ (💢❤️🗯️) 2019年7月16日 (二) 04:49 (UTC)
• 日文那两条应该可以并入“外文維基百科存在相同或非常相似的重定向”，不必保留。如果我们要原创日文维基百科没有的重定向，不可避免落入原创研究。~ viztor ✪ 2019年7月17日 (三) 06:14 (UTC)

建立的外文重定向语言必须为重定向目标标题的原文语言，非原文语言仅在中文社群中被广泛使用时才被允许。

1. 重定向標題與維基數據記錄的目標條目外文標題相同或非常相似；
2. 外文維基百科存在相同或非常相似的重定向，指向維基數據跨語言連結的外文對應條目（例如「zh:蘋果」存在跨語言連結"en:Apple"，已有"en:Malus domestica"重定向至"en:Apple"，則「zh:Malus domestica」重定向至「zh:蘋果」符合規定）；或为
3. 特殊非中文重定向：
   1. 時區：世界各地的時間UTC+8、GMT+8等等。
   2. 化学品CAS号：文献中所记载的每种化合物的唯一编码，如106-98-9→1-丁烯。
   3. Emoji符號可以根據Unicode定義的名稱（即Full Emoji List中的CLDR Short Name）可以建立指向該定義的重定向。
   4. 機場的ICAO代碼，如ZSSS（→上海虹橋國際機場）；

同时删除了注释性说明emoji和ICAO的两句，任何时候可能的外文重定向有歧义都应该按照WP:消歧义的标准建立消歧义页面，无需特别说明。很可能因为两条独立加入所以额外有说明，但整体来看是多余的。WP:KISS。作为最终条文，不知道有什么意见？~ viztor ✪ 2019年7月17日 (三) 07:13 (UTC)

• 基本上(＋)支持-- Vakrieger♀︎ (💢❤️🗯️) 2019年7月17日 (三) 07:42 (UTC)
• (＆)建議 解釋一下什麼叫「原文語言」，以免在非專有名詞出現爭拗。可以利用英文那邊的解釋，即「重定向目標與此語言（或操此語言的文化）有明確關聯」-- Vakrieger♀︎ (💢❤️🗯️) 2019年7月17日 (三) 07:45 (UTC)

还是应当给予英语特别待遇，因其为目前 de facto 世界语；以及给予罗马化特别待遇，因为中国人普遍熟悉拉丁字母。特别是人名或地名，若原文为西里尔字母、阿拉伯字母、天城体字母等，总之，非拉丁字母或汉字，则应允许建立其拉丁化转写的重定向。另外，混合重定向也需考虑。例如，应允许建立如“Toledo 翻译院”及“Riemann 曲面”这样的重定向。注意其中西文与汉字之间应有空格（或者，有空格和没有空格的都允许，因为重定向的一大功能就是纠正拼写错误）。--Cswquz（留言） 2019年7月17日 (三) 14:27 (UTC)

对“给予英语特别待遇”的说法不赞成。但不反对对中文来源中广泛使用的原文写法的情况下使用原文~ viztor ✪ 2019年7月17日 (三) 18:37 (UTC)

百科全书以实用为优先考虑。《中国大百科全书》的绝大多数条目都标注了英文名称，连比如说“斯大林”旁边都是标注英文而不是俄文或格鲁吉亚文。用英文的其余理由此处省略7万字。--Cswquz（留言） 2019年7月17日 (三) 20:12 (UTC)

《中国大百科全书》第一版“斯大林”条目的括注还是用俄文，第二版才是英文。第一版除了俄苏人名和地名用俄文，其余括注亦全用拉丁字母。--Cswquz（留言） 2019年7月18日 (四) 00:23 (UTC)

我的意见没有改变，维基百科的跨语言链接可以很方便的找到各种语言版本的条目，与纸质版本不同，我看不到优先使用英文的必要性。请注意，拉丁字母不一定是英文。~ viztor ✪ 2019年7月18日 (四) 07:32 (UTC)

那么至少你同意若原文非拉丁字母，则可建立其拉丁转写的重定向，这样理解对吗？--Cswquz（留言） 2019年7月18日 (四) 07:43 (UTC)

@Cswquz、Viztor：綜合兩位的意見，將條文改成這樣好不好？

“ 基於維基百科不是辭典，建立的外文重定向語言原則上應符合以下條件：

1. 此語言（或操此語言的文化）與目標條目有明確關聯（例如，公司／作品／人物／地方的外文原名），和／或
2. 有合理期望中文使用者會使用此語言指稱目標條目（例如，部分專業文獻常見之拉丁化外文人名）

”

-- Vakrieger♀︎ (💢❤️🗯️) 2019年7月18日 (四) 13:11 (UTC)

“常见”的固然应该允许，不“常见”的似乎更应当允许，因为目前中文维基的一个大问题就是译名混乱，允许专有名词（乃至部分非专有然而属于专业术语）的原文及其拉丁化转写的重定向正是出于解决此问题的需求。这在上面已经关闭的章节一开头就提到过。--Cswquz（留言） 2019年7月18日 (四) 13:45 (UTC)

再接着前边说说网络百科与纸质百科的异同。网络百科是可以用蓝链，然而并不是什么场合都能够点击蓝链，如打印出来或以幻灯、图片展示条目的时候。而且我觉得这种“有了X就用不着Y”的做法等于减少了一种冗余纠错，从而降低了系统的鲁棒性(robustness)。--Cswquz（留言） 2019年7月18日 (四) 13:55 (UTC)

• 另一種辦法就是允許所有原文非中文的專有名詞和派生自外文名的非專有名詞建立原文和英文重定向（因為這些通常在字典是查不到的）-- Vakrieger♀︎ (💢❤️🗯️) 2019年7月19日 (五) 22:26 (UTC)
  • 英文的話不太贊成，我認為需要獨立證明非原文英文重定向的常用性才能建立。산모사 ^DC17_{加泰隆尼亞圖書館GAN} 2019年7月25日 (四) 15:01 (UTC)

重整後提案

已通過-- Vakrieger♀ 💢❤️🗯️ 2019年8月14日 (三) 01:28 (UTC)

下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

---

如下：

中文維基百科原則上允許創建符合重定向方針的非中文重定向。創建者須在重定向頁面放置非中文重定向通告模板。創建者亦須在頁面底部提供證明此重定向外文名的可靠來源。

基於維基百科不是辭典，建立的外文重定向語言原則上應符合以下條件：

1. 此語言（或操此語言的文化）與目標條目有明確關聯（例如：公司／作品／人物／地方的外文原名），和／或
2. 有合理期望中文使用者會使用此語言指稱目標條目（例如部分專業文獻常見之拉丁化外文人名）；

否則一般而言並不應建立該外文重定向。

就此條文而言，以下情況亦可視為具有可靠來源，故而毋須依上述規定在頁面底部提供證明此重定向外文名的可靠來源：

1. 重定向標題與維基數據記錄的目標條目外文標題相同或非常相似；
2. 外文維基百科存在相同或非常相似的重定向，指向維基數據跨語言連結的外文對應條目（例如「zh:蘋果」存在跨語言連結"en:Apple"，已有"en:Malus domestica"重定向至"en:Apple"，則「zh:Malus domestica」重定向至「zh:蘋果」符合規定）；或为
3. 特殊非中文重定向：
   1. 時區：世界各地的時間UTC+8、GMT+8等等。
   2. 化学品CAS号：文献中所记载的每种化合物的唯一编码，如106-98-9→1-丁烯。
   3. Emoji符號可以根據Unicode定義的名稱（即Full Emoji List中的CLDR Short Name）可以建立指向該定義的重定向。
   4. 機場的ICAO代碼，如ZSSS（→上海虹橋國際機場）；

以上。我計劃三日後公示。산모사 ^DC17_FLC 2019年7月31日 (三) 01:33 (UTC)

• (＋)支持 -- Vakrieger♀︎ -- 💢❤️🗯️ 2019年7月31日 (三) 12:35 (UTC)
• "創建者亦須在頁面底部提供證明此重定向外文名的中文可靠來源"为什么必须要中文来源？为什么外文維基百科存在相同或非常相似的重定向，中文版也就可以用？不同语言，情况差异会很大--百無一用是書生 (☎) 2019年8月1日 (四) 02:53 (UTC)
  • 要求中文來源是為了解決某巡查擔心的小語種無人可查證的問題。至於外文存在重定向，這並不是重定向可以在中文版存在的充分理由，只是針對可靠來源要求的豁免標準——重定向最終還是要符合第二段寫的那兩條標準之一。-- Vakrieger♀︎ -- 💢❤️🗯️ 2019年8月1日 (四) 13:16 (UTC)
    • 小語種無人可查證的可能性极其小。为了解决这个问题把问题扩大化，要求必须中文，完全本末倒置啊--百無一用是書生 (☎) 2019年8月2日 (五) 02:54 (UTC)
    • 那就取消可靠來源必須中文的要求吧，我不反對 -- {=> Vakrieger♀ <=} 💢❤️🗯️ 2019年8月2日 (五) 08:49 (UTC)

我还是坚持强烈建议给予英语特别地位。我总怀疑那些将英语视作普通外文、认为汉语在中文维基的地位可以完全等同于英文在英文维基的地位的人，是否有足够的编辑特别是翻译经验，本身又读过几篇文献。重定向是便宜的，不要为了一些形而上的理念而给百科编辑者设置不知所谓的限制。--Cswquz（留言） 2019年8月3日 (六) 12:44 (UTC)

我不會容許“给予英语特别地位”這個情況發生，不要盲目英文至上（而且英文已經是很多語言的原文了，已經夠了）。我個人也非常反對“重定向是便宜的”這個説法；老實説，查證成本一點也不“便宜”。산모사 ^DC17_{GAC FLC} 2019年8月4日 (日) 09:54 (UTC)

即日起公示。산모사 ^DC17_{GAC FLC} 2019年8月5日 (一) 01:28 (UTC)

“我不会容许”，问题是，who do you think you are? “英文至上”是一个事实陈述而已，你喜欢或者不喜欢，现实就是如此（我其实就不满意这种现状）。百科全书是为了给读者提供方便，不是推行某部分人的某种理念的所在。--Cswquz（留言） 2019年8月5日 (一) 23:25 (UTC)

举一个以前提到过的例子，“朗布尔县”条目，又译“蘭格普區”，原文是“রংপুর“，你觉得把这样的原文作成重定向更有用，还是将其英译“Rangpur District”作成重定向更有用？--Cswquz（留言） 2019年8月5日 (一) 23:31 (UTC)

还有古希腊学者，阿拉伯学者，甚至是比较常见的俄苏人名或地名，对中国人来说，其原文都远不如英文名用起来方便。--Cswquz（留言） 2019年8月5日 (一) 23:36 (UTC)

乌孜别克语传统上使用阿拉伯字母，1940年改用西里尔字母，1993年又改用拉丁字母；土耳其语传统上使用阿拉伯字母，1928年改用拉丁字母。--Cswquz（留言） 2019年8月6日 (二) 07:58 (UTC)

• • @Cswquz：我同意您的現實考慮，但現實也是如果把「英文優先」直接寫進方針難免會讓不少人感到不適。不妨將方針維持原狀，另起一篇 RDRNC 的解釋性指引，列明「原文非拉丁字母時使用拉丁化字母作為重定向符合『有合理期望中文使用者會使用』的標準」？-- Vakrieger♀ 💢❤️🗯️ 2019年8月6日 (二) 12:10 (UTC)

那先这样吧，我这里是提出一些保留意见，供今后继续修订时参考。整体来讲不反对。至于细则解释，唔，这次风波已经延续两个多月了，先偷个懒吧。等以后若再有哪位责任心高过学识水平的巡查引发了争议，到时候再说。--Cswquz（留言） 2019年8月6日 (二) 14:15 (UTC)

• 我在這裏解釋一下為何我那時說「我不會容許」：我當時看到的社群意見很明顯反對這樣的做法，所以我的想法是除非他的主張能夠突然獲得社群主流支持，否則他不能強行提案加入那條，或因為提案沒有那條而反對提案。既然他已經表明對此提案不反對的話，那我也不會說些甚麼。산모사 ^DC17_{GAC FLC} 2019年8月7日 (三) 02:33 (UTC)
  • 另外，我個人認為「有合理期望中文使用者會使用此語言指稱目標條目（例如部分專業文獻常見之拉丁化外文人名）」條已經給予了英文重定向很大的寬容度，如果再加入相關條文，有機會會導致效用重複。산모사 ^DC17_{GAC FLC} 2019年8月7日 (三) 02:35 (UTC)
• 感謝諸位發表高見。我希望這次提案終於能根治 RDRNC 界定模糊的問題，了結此次風波。-- Vakrieger♀ 💢❤️🗯️ 2019年8月7日 (三) 14:10 (UTC)

---

本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

---

• 請問可否簡述本方針在提案前後的差別？有些不明白。—— Eric Liu_{（留言．留名．學生會）} 2019年8月13日 (二) 05:13 (UTC)
  • User:Ericliu1912新提案通過後，會有大量原本不符合RDRNC的重定向變成符合RDRNC，原本就符合RDRNC的新提案通過後仍然符合（e.g. 「Pedro de Alcântara Francisco António João Carlos Xavier de Paula Miguel Rafael Joaquim José Gonzaga Pascoal Cipriano Serafim de Bragança e Bourbon」在新提案通過後可以重定向到「佩德罗一世 (巴西)」，因為這是巴西皇帝佩德罗一世的葡萄牙文全名，但以前的RDRNC並不容許）。산모사 ^DC17_{GAN FLN1 FLN2} 2019年8月13日 (二) 06:13 (UTC)

原来的也没说不允许，是某位巡查理解错误才引发此次修订。不要总以为别人不怀好意。像上面这个皇帝这种极端例子，相信也没有什么人会去建立，就算建了，重定向是便宜的，不理他便是。--Cswquz（留言） 2019年8月13日 (二) 09:41 (UTC)

其實嚴格理解的話，原方針應該是不允許此類的重定向；我找個嚴格理解方針的管理員解釋條文，就能達到這樣的效果。산모사 ^DC17_{FLN1 FLN2} 2019年8月14日 (三) 00:03 (UTC)

你总想诉诸威权，这样的思维方式在维基就不对头。应该是这样：如果有人大量的利用规则恶作剧，那么可以WP:GAME论处。--Cswquz（留言） 2019年8月14日 (三) 00:23 (UTC)

方针翻译及整合建议

英文维基有一篇《WP:外文重定向》，建议翻译，并在之后将现在正在讨论修改的这个方针合并进去。但是注意这里就涉及我一再提到的，英文和中文的最大不同是前者为事实上的世界语，后者不是，所以除了允许原文，还应允许英文的重定向，特别是专有名词。--Cswquz（留言） 2019年8月3日 (六) 13:02 (UTC)

撤回翻译此篇的建议。--Cswquz（留言） 2019年8月5日 (一) 23:16 (UTC)

題外話：關於捷徑

大家好。考慮到現有捷徑 RDRNC, RNOTC, REDIRNC 不符合通常英文語法，不方便記憶，我建立了幾個新的：

• WP:RFAL - Redirects From Alternative Language
• WP:NCR - Non-Chinese Redirects
• WP:FORRED - Foreign Redirect

我更新了方針頁面中的捷徑，但原來的那幾個也不要刪除。如果諸位不同意，直接回退即可。-- Vakrieger♀ 💢❤️🗯️ 2019年8月14日 (三) 01:47 (UTC)

现在就看Wikipedia:頁面存廢討論/記錄/2019/05/29#不合WP:RDRNC的重定向 积压的75个提删能不能 lift 了。--Cswquz（留言） 2019年8月14日 (三) 03:06 (UTC)

將Wikipedia:關注度 (虛構事物)立為指引

• 先前討論無共識，因此重啟。敘述已足，基本適宜作為指引。--MeritTim_{（留言-給予警告）} 2019年2月16日 (六) 11:23 (UTC)
  • 基本(＋)支持本提案，但看到最後提案人不再理會提案我感到十分遺憾。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月13日 (二) 07:54 (UTC)
• (－)反对，直到討論頁的問題全被解決。--Temp3600（留言） 2019年2月17日 (日) 11:12 (UTC)
  • (？)疑問@Temp3600：想問一下您現在的想法，明顯的反對表態只剩此處，所以想問一下您現在的此案的想法或看法，感謝。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月2日 (二) 13:03 (UTC)
    • 收回此說法，現在出現了其他爭議。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月18日 (四) 06:31 (UTC)
      • 其他爭議正在討論中-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月28日 (日) 05:53 (UTC)
        • (？)疑問請問@Temp3600：近期有空參與此議題的討論嗎？-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月9日 (五) 07:05 (UTC)
• @Temp3600：作为现版本起稿人，不知道还有什么问题需要调整，或者这个版本有什么执行问题？——路过围观的Sakamotosan | 避免做作，免敬 2019年2月17日 (日) 13:52 (UTC)

• 如果cwek君有意討論，當然歡迎。我們不如從虚构事物列表開始?另外，你對英維對應討論頁"Is this TV series even notable?"一節有什麼見解?--Temp3600（留言） 2019年2月17日 (日) 14:06 (UTC)
• 虚构事物列表（包括人物、世界观等），应该先做内容整理，尽量做到都有来源，然后参照篇幅占比并讨论后才考虑独立分割。对于经常有些未经讨论下就分割出去的列表条目，的确是头疼事。——路过围观的Sakamotosan | 避免做作，免敬 2019年2月18日 (一) 02:04 (UTC)

• 哈哈，這個頭痛事就是我們今日的討論重點嘛。這個話題三年前我們交過手，現在再遇，確是幸事。如果按這份指引，應如何處理盾之勇者成名錄角色列表?沒有任何來源的角色列表，應如何處理?我先開一槍:如果連第一方來源都沒有的頁面，視為廣告內容，可AFD。您有何見解?--Temp3600（留言） 2019年2月18日 (一) 09:12 (UTC)

合并最快，就条目内容而言，合回主条目，最多是另条目质量下降而需要时间改善，独立出来就要考虑关注度作为条目存在门槛的要求。关于分割部分就是放了这么久考虑出来的。——路过围观的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)

• 那這個部分先打住。我們回去獨立列表的規則上。--Temp3600（留言） 2019年2月22日 (五) 16:57 (UTC)

• 獨立列表的收錄準則（關注度）似乎需要視為本次議案的重點之一。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月18日 (四) 08:55 (UTC)
  • (：)回應@Temp3600：新討論的結論已列於#虛構列表收錄準則，歡迎指點。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月31日 (三) 09:31 (UTC)

• 对于"Is this TV series even notable?"，应该是指对于来源的使用导致判断关注度的问题？这个条目的确有些问题，过于依赖一手性质的来源（不清晰的本书说明引用，和来源于改编播放组织的评价）。我认为虚构作品及事物，既要有由一手或二手合要求来源描述其本身和剧情描述，更重要的有二手的合要求来源描述其对现实的影响或现实对其的评价（例如说明销量或者因为销量而产生的评价等）。——路过围观的Sakamotosan | 避免做作，免敬 2019年2月18日 (一) 02:14 (UTC)

• 如何看待裏面提出的"跨媒體作品，除非各部分有明顯的獨立關注度，否則應由同一條目包括"的原則?--Temp3600（留言） 2019年2月18日 (一) 10:20 (UTC)

• 一个特定作品或系列的改编共在一个条目上是常规做法，只是一般情况下，如果篇幅足够而且某个改编也有自身足够的关注信息的话，才考虑独立分割出去。总而言之，分割的原则是整理内容，篇幅需要，讨论。——路过围观的Sakamotosan | 避免做作，免敬 2019年2月18日 (一) 12:45 (UTC)
• 那麼我希望這一點能明文表達出來。--Temp3600（留言） 2019年2月19日 (二) 13:53 (UTC)

拆分合并问题，并不影响整个Wikipedia:關注度 (虛構事物)的通过吧？如果仅仅是拆分合并问题上无法达成共识，那么在指引中把它注明一下就可以了。不应该仅仅为了其中一小部分问题，而把整个指引废掉--百無一用是書生 (☎) 2019年2月19日 (二) 03:58 (UTC)

拆分列表是虚构作品类经常出现的问题，而且本来已有的方针指引中对列表的态度仍然不太完善，所以单独在这个系列上做操作完善。不过原则上已经说明应该怎样操作。对于其他部分不知道有没疑问？这玩意16年定初稿，讨论剩下列表部分，已经够长了。 囧rz...——路过围观的Sakamotosan | 避免做作，免敬 2019年2月19日 (二) 08:15 (UTC)

拆分列表問題是這類條目的核心問題，繞過它的指引我覺得意義不大。--Temp3600（留言） 2019年2月19日 (二) 13:53 (UTC)

這部分我認為是本次要解決的問題之一。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月18日 (四) 08:55 (UTC)

• (：)回應@Temp3600：新討論的結論已列於#虛構列表收錄準則，歡迎指點。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月31日 (三) 09:31 (UTC)

• 兩件事：於「虚构作品」下添「獨立列表」一項，列明每個二級標題下面最少需要一個第一方來源，證明所寫的人物群/設定群確實存在。評價部分未想好如何規範。
• 列明跨媒體作品需得到獨立第三方介紹方可分柝特定媒介的頁面。--Temp3600（留言） 2019年2月22日 (五) 17:30 (UTC)

@Temp3600：，后者已补充。对于独立列表，主要要考虑从一个整体将其细项单独分割出来的列表条目是否与其整体条目有相连的关注度要求，如果相连的话，则视列表条目是整体条目的延伸而关注度由整体条目声明。还是前言，本社群对列表条目的存在还是不够明晰，导致了许多类似XX人列表、剧情列表类似的存在而且有容许这些条目的存在。——路过围观的Sakamotosan | 避免做作，免敬 2019年2月24日 (日) 08:10 (UTC)

• 這兒先放着。如果下面條目範圍解決掉，這兒的獨立列表問題可以順勢解決。另外我希望多邀請一些編輯來討論關注度問題-始終只有我們兩個不算是很好的共識。--Temp3600（留言） 2019年3月1日 (五) 17:32 (UTC)
  • 應該有機會，但需要一點時間。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年3月9日 (六) 09:49 (UTC)
    • 主要與非主要事物界定有望達成共識，應該有機會定出虛構事物收錄準則。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年3月14日 (四) 06:31 (UTC)
      • 條目範圍是解決掉了，不過現在出現了其他異議。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月18日 (四) 08:55 (UTC)
        • (：)回應「這兒的獨立列表問題可以順勢解決」我還真希望可以解決，希望如果您有空的話可以來發表些意見。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月25日 (四) 16:49 (UTC)
          • (：)回應@Temp3600：新討論的結論已列於#虛構列表收錄準則，歡迎指點。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月31日 (三) 09:31 (UTC)
    • (～)補充：上方Wikipedia:互助客栈/方针#主角定義問題在遊戲角色方面尚未達成共識，歡迎參與討論，踴躍發表意見，以取得共識，感激不盡。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年3月20日 (三) 13:13 (UTC)
• 完成：移動議題到此，待上方討論收束後，此塊繼續，並讓上方存檔，特此告知。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年3月25日 (一) 09:48 (UTC)
  • 四月的討論比較集中在性質表與資料頁的指引建構，相關討論可以前往Wikipedia_talk:维基百科不是什么#提議設立WP:IINFO內容改善流程查閱。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月18日 (四) 08:55 (UTC)
• 引述「@Temp3600：始終只有我們兩個不算是很好的共識」，那麼我現在對此案表示(＋)支持，這樣就多一個人了。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年5月31日 (五) 08:18 (UTC)
• 此留言已被原作者（User:和平至上）移除。2019年6月26日 06:11 (UTC)

  對於一個連續跨度5個月的討論，在最後一刻突然提出（節刪）不是要改進的意見，（節刪）可能有點浪費社群資源，我感到有一點遺憾。 （節刪）建議是針對可改進的地方提出改進（節刪）。--宇帆（留言·歡迎簽到_R₁R₂NKC） 2019年6月9日 (日) 18:19 (UTC)

  • 該指引草案有多次於存廢討論被當指引應用並被採納的例子，例如WP:AFD/2008/6/8#派隆、WP:AFD/2009/6/8#動漫畫眼鏡女性角色列表、WP:AFD/2009/6/8#双马尾动漫人物、WP:AFD/2010/6/8#晓_(火影忍者)、WP:AFD/2012/6/8#蛇眉銅魚、WP:AFD/2012/6/8#金属小队、WP:AFD/2012/6/8#水鏡八奇、WP:AFD/2018/6/8#雨傘鬼，認為「不見得有什麽必要特地訂立一個指引，而且其他部分也過於空泛」（節刪）不是一個好理由，見最近一次WP:AFD/2018/9/9#血小板_(工作细胞)中User:hat600於「2018年9月12日 (三) 04:55 (UTC)」的發言（這個例子可能不好）

  ，以及下方User:Cwek的發言，認為共識已足（節刪）。--娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年6月22日 (六) 08:16 (UTC)

  此留言已被原作者（User:和平至上）移除。2019年6月26日 06:11 (UTC)

  相应的讨论，以存档索引：Topic:V2c18otya03ygl5o。——路过围观的Sakamotosan | 避免做作，免敬 2019年6月26日 (三) 06:28 (UTC)

  • 我來說明一下，對於「我們已經討論完了，移動到這裡只是裝裝樣子」首先根本還沒討論完，而且也不是新討論，也不是移動到此，是一直都在這裡。此案由MeritTim_{（留言-給予警告）}2019年2月16日(六)11:23(UTC)提出時本來就是在Wikipedia:互助客栈/方针裡面，但1天後，爆發Wikipedia:頁面存廢討論/記錄/2019/02/17#盾之勇者成名錄角色列表大型爭議後，U:Temp3600於2019年2月18日(一)14:01(UTC)說明要處理此案，因此繼續在Wikipedia:互助客栈/方针，但為了使Template_talk:关注度标准导航#關注度論述共識討論能夠順利存檔，並能夠有效地繼續針對議題繼續討論，因此對討論段落結構調整，接著是歷時5個月的長期討論，因為有些小段已達成共識先行存檔，因此可能會有討論是被移動過來的錯覺，但事實上討論仍再繼續，然後由於User:Milkypine於2019年4月23日(二)16:33(UTC)認為這串的長度真的長到有點不想留言，因此跟User:Sanmosa商議後決定先把討論完的章節全部存檔，導致這則討論掉了出來，而不是「我們已經討論完了，移動到這裡只是裝裝樣子」，希望您理解，如果我的行為讓你感到反感，我很抱歉，如果有甚麼還需要改進之處，請直接指出，感謝，很高興看到您願意加入討論。

  上述可能有爭議的字眼已「（節刪）」如還不夠請告知，我可以整段移除，但考慮到討論前後完整性，因此沒有全部移除。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年6月30日 (日) 09:17 (UTC)

  • 再看看還有沒有其他意見。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月7日 (日) 10:17 (UTC)

  • (：)回應，因为这个指引草案引述了一些共同的操作说明，但针对独特的部分仍有不同，而且也针对一些特别的情况（例如处理方法）而说明。由于涉及分割的部分仍缺乏合适的规则支持，所以我也暂时搁置这部分的改善。至于其他关于具体的操作，讨论良多，可以自行翻存档。——路过围观的Sakamotosan | 避免做作，免敬 2019年6月3日 (一) 01:05 (UTC)
  • 如果简单而言，因为这个草案是根据Wikipedia:關注度 (書籍)做骨干的，所以和它相仿并不足奇。——路过围观的Sakamotosan | 避免做作，免敬 2019年6月3日 (一) 01:08 (UTC)
• (＆)建議更名為Wikipedia:關注度 (虛構作品及虛構事物)，雖然這名稱有點長，但這能更好地傳達内容的重點，如果有更好的用字，當然更好。--【和平至上】💬📝 2019年6月26日 (三) 06:18 (UTC)

  我认同。可能需要一次单独的投票决定？——路过围观的Sakamotosan | 避免做作，免敬 2019年6月26日 (三) 06:28 (UTC)

  我覺得索性用「Wikipedia:關注度 (虛構)」這個名字好些，不過看大家意見，反正我對於命名沒太大所謂。Σανμοσα 2019年6月26日 (三) 09:08 (UTC)

• (＋)支持：至於名字要叫甚麼，你們決定就好（我是真的覺得沒差啦）。 --船到*橋頭*往日不再 2019年6月28日 (五) 05:19 (UTC)
• (＋)支持，意見同Milkypine閣下。—— Eric Liu_{（留言．留名．學生會）} 2019年7月2日 (二) 05:24 (UTC)
• 已經閒置了幾天了，還有反對意見是未解決的嗎？--【和平至上】💬📝 2019年7月8日 (一) 17:52 (UTC)
  • 指引內容是可以視為已達成共識，(？)疑問但指引命名的部分可能還有分歧？。目前已提出的名稱有：關注度 (虛構事物)、關注度 (虛構)、關注度 (虛構作品及虛構事物)。 我認為「虛構實體」或「虛構主題」？-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月9日 (二) 10:33 (UTC)
    • 這個問題的原因在於「虛構作品」及「虛構事物」中「虛構」的意義有所不同。前者是指作品的內容是虛構，而後者的意思則是整個事物都是虛構的。「虛構實體」或「虛構主題」好像都未能同時表達「內容是虛構」的虛構作品和「存在是虛構」的虛構事物兩種意義，所以我才建議寧願用長一點但是更準確的用字。--【和平至上】💬📝 2019年7月9日 (二) 15:35 (UTC)

      抱歉，對不起打擾一下，我有一個疑問想請教一下和平至上君，就是您接不接受《關注度 (虛構)》一寫法，這個疑問解決了就有機會達成共識，非常感謝，祝編安。抱歉打擾了。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月14日 (日) 10:49 (UTC)

      • 名字可以先用「關注度 (虛構事物)」，畢竟標題這麼寫，先讓他成為指引，再討論名字是否需要更改。 --無心*插柳*柳橙汁 2019年7月9日 (二) 16:02 (UTC)
      • 我反而認為單用“虛構”並無不妥，一詞多義很常見吧，再不然在指引首段再定義一次就好。산모사 ^DC17 2019年7月10日 (三) 14:49 (UTC)
    • (？)疑問@SmallTim：最初提案人，您有甚麼看法？-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月11日 (四) 09:34 (UTC)
• @SmallTim、和平至上、Temp3600：有空的話回應一下我的疑問吧。萬分感謝。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月15日 (一) 10:17 (UTC)
  • 我並沒有任何想法，抱歉。SmallTim 2019年7月15日 (一) 10:25 (UTC)

    (！)意見，我認為作為一案的提案人，到最後出現爭議就逃跑不再發表意見，是個不當的行為。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月13日 (二) 07:52 (UTC)

    • 那我就視同您SmallTim仍繼承2019年2月16日 (六) 11:23 (UTC)時間戳之看法。 若再過一周未見U:Temp3600答覆則視為繼承U:Temp3600與U:Cwek之共識。其餘部分則是名稱，-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月15日 (一) 12:41 (UTC)
      • (？)疑問不曉得您U:和平至上對《關注度 (虛構)》看法如何？其他名稱可以透過重定向來重定向過去。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月15日 (一) 12:44 (UTC)
        • 大家都覺得可以那就用這個吧，因為這也不是那麼重要，浪費時間在這個上好像有些無謂。--【和平至上】💬📝 2019年7月15日 (一) 12:50 (UTC)
• @A2569875：准则部分可以，其他部分不宜。~ viztor ✪ 2019年7月16日 (二) 05:53 (UTC)
  • @cwek：-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月16日 (二) 06:21 (UTC)

@viztor：then？——路过围观的Sakamotosan | 避免做作，免敬 2019年7月16日 (二) 06:27 (UTC)

把那一节定为指引就可以了。~ viztor ✪ 2019年7月16日 (二) 06:59 (UTC)

(？)異議我覺得《關於獨立虛構事物、跨媒體改編作品及列表的分割》﹑《準則》﹑《處理方法》都是指引。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月16日 (二) 07:22 (UTC)

指引不是指南，仅规则性内容可以作为指引~ viztor ✪ 2019年7月16日 (二) 07:27 (UTC)

“關於獨立虛構事物、跨媒體改編作品及列表的分割”本身就涉及了“虚构事物”的范畴，当然你觉得有点啰嗦，但实际上这已经给出判断和处理方法。至于“处理方法”实际上更多对“虚构事物”处理方法上的补充，也是对惯例处理的确认，对于“虚构作品”的处理方法和通用关注度原则上是一致的。如果你认为只有规则性内容才是指引，请看Wikipedia:关注度和Wikipedia:關注度_(書籍)。——路过围观的Sakamotosan | 避免做作，免敬 2019年7月16日 (二) 07:37 (UTC)

““虚构作品”的处理方法和通用关注度原则上是一致”，如您所说，这里仅仅是对关注度指引中的补充说明，本身没有规范任何新的东西。~ viztor ✪ 2019年7月17日 (三) 06:53 (UTC)

那就说明了你没理解“原则一致”和“细则不一致”的问题。如果按照你的说法，实际上根本不需要各细致的关注度细则——因为他们本质就是“原则一致”，然后在关注度原则的基础上补充说明。——路过围观的Sakamotosan | 避免做作，免敬 2019年7月17日 (三) 07:00 (UTC)

請就「原則一致」和「細則不一致」進行答覆。@viztor：-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月17日 (三) 19:29 (UTC)

• (？)異議我覺得《關於獨立虛構事物、跨媒體改編作品及列表的分割》﹑《準則》﹑《處理方法》是規則性內容，不是指南。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月16日 (二) 12:29 (UTC)

处理方法在任何时候都不是。"关于独立虚构事物、跨媒体改编作品及列表的分割"这一段和其他类型的拆分没有本质区别，再者和关注度关系不大，本质上是在对其他方针/指引在针对虚构事物的具体情况下做了案例说明。~ viztor ✪ 2019年7月17日 (三) 06:47 (UTC)

部分关注度是有包括处理方法，虽然大部分的处理方法是一致的。而对于“虚构事物”而言，由于其内容性质的问题，将一些已有的操作惯例明文规范化作为额外的操作处理，剔除这一小部分，还是和通用的处理方法一致。——路过围观的Sakamotosan | 避免做作，免敬 2019年7月17日 (三) 07:08 (UTC)

对于列表的话，主要可以从关注度或者提删合并入手。因为基本上商定了可以用Wikipedia:资料页去解决，所以只是提及。但对于略微常见的从一个作品中拆离出一个事物作为独立条目的情况，这个说明还是比较有意义。至于里面提到的一个例子（妖精尾巴 (虛構組織)），这是我所留意到比较特殊的案例，既像事物列表，但本质上更应该是事物条目，而且某种意义上更像不太合规的反面教材。——路过围观的Sakamotosan | 避免做作，免敬 2019年7月17日 (三) 07:30 (UTC)

关注度细则并不包含所谓的处理方法包括你上述提及的WP:关注度 (书籍)，这里也没有提议新的流程。所有关注度的流程都应该是一致的，其他的细则只是定义了由于领域不同而通用关注度指引不适用的情况。规范特别的流程本身是没有道理的，而且可能过度复杂化。~ viztor ✪ 2019年7月17日 (三) 07:50 (UTC)

除了针对虚构事物的处理方法是一点增多的差异外，处理方法的其他部分其实就是复读通用关注度而已。——路过围观的Sakamotosan | 避免做作，免敬 2019年7月17日 (三) 08:12 (UTC)

請就「針對虛構事物的處理方法是一點增多的差異」進行答覆。@viztor：-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月17日 (三) 19:31 (UTC)

(？)異議未見頁頂標註「本頁為指引」有何不妥之處；(？)異議未見任何關注度指引只有半頁是指引的情況；(？)異議不應沒事開先例；(？)異議未見此種開先例的必要性；(？)異議未見此關注度指引有需要有別於其他關注度指引升為指引之模式。(！)抗议半頁指引。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月17日 (三) 10:42 (UTC)

{{抗议}}, 您这是要坚持打包通过吗。~ viztor ✪ 2019年7月17日 (三) 18:34 (UTC)

(？)異議這些內容是跨度5個月討論的共識，沒有所謂「打包」的理由。是有共識通過，其餘討論已存檔到維基百科不是甚麼的討論頁，請自己去看。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月17日 (三) 18:36 (UTC)

“ ::若有約定，則為共識。既為共識，則宜立為指引。--J.Wong 2018年7月25日 (三) 09:01 (UTC) ”

（引述自Wikipedia_talk:模板樣式）-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月17日 (三) 18:41 (UTC)

并非，通常前期讨论可能是关注此议题的人讨论，公示的目的是确定其他不太关注的人可以参与讨论。因为此前有讨论而否认公示后讨论的正当性完全是无关且早有共识的议题。您这样的说法等价于“小圈子共识”可以完整代替共识。倒不如专注讨论现有提案的问题，而不是让别人不要讲话。~ viztor ✪ 2019年7月17日 (三) 18:43 (UTC)

「分割前，應先考慮是否需要進行清理，並請參照相關同類事物的列項內容與所占主題條目的內容過多時才考慮列表分割，並分割前需要進行討論」就是要規範分割需要事項「若有約定，則為共識。既為共識，則宜立為指引」，若無法成為指引約定，則完全與本案立意背道而馳。本案主要爆發原因是Wikipedia:頁面存廢討論/記錄/2019/02/17#盾之勇者成名錄角色列表，之後連續煮了半年，結果你把重點之一反對掉，那就根本沒有解決問題，半年的討論完全白費。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月17日 (三) 18:53 (UTC)

這邊立成指引的話，「並分割前需要進行討論」，沒討論就分割者將可以依照關注度流程始提刪，有機會可以讓類似條目創建者避免激烈的衝突，不咬新手。此外，此案根本就還沒進入公示階段。沒關係，我們慢慢來，很快就可以成為第二個維基之最，跨度最長未存檔停留客棧的討論，每次客棧只要有關注度議題大家都誰也不讓誰互煮蟲蟲飛是否有同感？-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月17日 (三) 19:04 (UTC)

• 「否認公示後討論的正當性」(※)注意：此案根本沒有公示、此案根本沒有進入公示階段，何來「公示後討論」？-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月17日 (三) 19:15 (UTC)
  • 公告版上目前的公示就只有「[公告] 頁面存廢討論及合併請求整合問題已經進入公示階段，如有意見則請務必盡快提出。」哪邊看到有「XX關注度指引進入公示階段」？而且我也沒看到有任何用戶在此案任何地方宣布「現交付公示」的字樣。 本案仍然維持在討論階段，只是即將跨到第六個月份而已。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月17日 (三) 19:38 (UTC)

(！)意見虛構事物列表的分割 必須是指引，不然又會再出現像盾之勇者那樣的爭議。 當然細節可能還需開一個討論來進行。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月17日 (三) 10:58 (UTC)

如果要对分割定指引，和关注度就没有关系了。自己想想吧。~ viztor ✪ 2019年7月18日 (四) 04:28 (UTC)

@viztor：如果分割出来的是一个单独的虚构事物的话，本质还是按照本指引处理；如果是列表的话，主要是在Wikipedia:资料页之前，对于列表的处理或者建立标准并不明确，部分草案性质的规则只有允许以篇幅可读性来分割，而普遍上列表也会被当成条目按照关注度来处理，所以当时编写时以长度和讨论结果为判断因素。当然有资料页指引的话，可以以此作为最核心的规则，而长度和讨论还是可以作为一个考虑因素。——路过围观的Sakamotosan | 避免做作，免敬 2019年7月18日 (四) 05:54 (UTC)

如果本指引成立的话，本指引确定了：如何按照本指引去分割一个事物列表；资料页指引定义怎样去建立合规的列表；如果一个看似是分割的但不合规的事物列表按照本指引应该怎样去处理。——路过围观的Sakamotosan | 避免做作，免敬 2019年7月18日 (四) 06:34 (UTC)

• 現在的癥結點在哪裡啊? --無心*插柳*柳橙汁 2019年7月16日 (二) 06:36 (UTC)
  • 就我主張全部升指引，然後準備要公示時被人叫停。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月16日 (二) 07:42 (UTC)
    • (：)回應User:Milkypine現在的癥結點在有人主張「虛構事物分割列表的關注度」以及對應的「處理方法」不得升為指引，這將導致Wikipedia:頁面存廢討論/記錄/2019/02/17#盾之勇者成名錄角色列表所點出的問題，花了五個多月完全沒有解決。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月17日 (三) 19:49 (UTC)
      • 都9102年了，指引有沒有詳細說明又不會死，表格上色不就是這樣，一堆人還以為是理所當然結果每年都在發生。 --無心*插柳*柳橙汁 2019年7月18日 (四) 04:08 (UTC)
        • (！)意見如果全部都依照WP:常識的話，那麼往往會因為某些人在常識認知上的微小出入而造成許多編輯爭議。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月19日 (五) 08:41 (UTC)
    • 突然吵起來了。我看再等6個月後再考慮要不要公示好了。^{[開玩笑的]}（關注度議題真可怕，每逢關注度議題就會炸出維基之最，例如下方的方針客棧存檔#关注度程序30日过长。）-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月18日 (四) 06:18 (UTC)

(＋)支持：這個收錄標準可以令大家不用太依賴《通用關注度指引》，令維基的內容更豐富，更精彩。英文維基類似的不同類型的收錄標準更多呢，而且編輯都能嚴格依從。--蟲蟲飛♡♡→♡℃※留言 2019年7月18日 (四) 00:32 (UTC)

(？)疑問@蟲蟲飛：您認為草案中的子章節：《關於獨立虛構事物、跨媒體改編作品及列表的分割》﹑《處理方法》也能升為指引嗎？如果是，理由？如果不是，理由？（我自己的看法是要升指引；「減少咬新手」論；以及避免AFD出現「XXX不是指引，內容僅供參考」的「本頁根本無效」之反對理由）-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月18日 (四) 06:21 (UTC)

• 作為一個收錄標準的指引，最重要的是WP:虛構準則這個章節，這裏規定了符合甚麼條件才可以收錄，其中第一個條件其實是《通用關注度》的要求，可以刪去。其他章節其實不重要，是否應一併升格為指引，我沒所謂，因為與收錄條件的關係不大。蟲蟲飛♡♡→♡℃※留言 2019年7月18日 (四) 07:21 (UTC)

• (！)意見「虛構事物列表收錄準則」亦是一個重要的收錄準則，否則每天AFD來AFD去，新手都被嚇怕走光了，就算關注度縮成14天，新手至少也有14天的時間可以改善，不會每天整天AFD來AFD去。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月18日 (四) 09:02 (UTC)
  • (：)回應@蟲蟲飛：這個議案為何會討論出這樣結論？這就要從盾之勇者成名錄角色列表開始說起，主要的爆發點是起源於Wikipedia:頁面存廢討論/記錄/2019/02/17#盾之勇者成名錄角色列表的提刪。那麼我來討論Wikipedia:頁面存廢討論/記錄/2019/02/17#盾之勇者成名錄角色列表吧。盾之勇者成名錄角色列表是甚麼問題呢，非百科內容?我並不這麼認為。當時為何會這麼提刪? 因為有一段論述這樣寫「若本章節過於龐大，請檢視並清理不必要的細節。之後將本章節整個以新條目分割，並且明記編輯摘要以符合版權協議。分割出的條目名稱建議設為「○○角色列表」（○○為作品名稱）。分割後原處應該有概要或簡列數名主要角色訊息。獨立列表請參見Category:虛構角色列表。」而新手在不明白的情況下建立了盾之勇者成名錄角色列表但問題來了，為什麼說是問題呢?因為當時這些相關內容不是指引，而該新用戶也只是單純地將原本位於盾之勇者成名錄的內容給獨立出來的，由於缺乏相關收錄準則，甚麼是收錄準則，其實可以視為一種關注度準則，但由於缺乏相關收錄準則，因此對於能否收錄出現了極大爭議，且不止一次，這個並非兩三句話就能讓新手明白，因此我們花了四個月立了一個資料頁指引，亦即給出IINFO的最大限制，超出限制後就是IINFO可以提刪，但提刪前可以有一段緩衝期檢視是否可以將內容根據某個準則縮短成符合社群能接受的樣子，當然如果寫的是「要有現實世界影響內容」「加上評論, 開發過程,etc」「不要幾萬bit完全寫劇情」是沒甚麼爭議，但顧及內容完整性我們必須訂出哪些是維基百科需要的內容而哪些不是，不是的可以移除，等等，獲得了共識之後立了WP:資料頁他跟獨立列表的差別在於，WP:資料頁所列的內容若不符WP:資料頁準則則可以整個視為IINFO。 接著就是Temp3600所提出的「請問目前指引出那一條可推導出「盾之勇者成名錄角色列表應合併回主條目」?我覺得目前這部分描述不太清晰。角色列表，世界觀列表是否必須有獨立的關注度?我個人則認為這兩者是關注度可繼承自主條目的特例，所以我上面不要求存在獨立的第三方來源。但是，支持獨立列表的最低來源要求又是什麼呢?」那麼這時我們需要特化的關注度指引，於是此案列於該案臨時動議，我並不認為目前這樣叫做沒有共識。在舊的存檔下，有十分多主編ACG的用戶參與討論，我們討論出了一套社群基本上能接受屬於虛構事物在還沒到IINFO之前的收錄準則，而這個收錄準則就是目前這個指引，我問為目前共識已足，如果已經有規範立為指引未見不妥，其他用戶便可以參照此指引完善相關條目，可見對維基百科是有益的，當然你點出的問題是可以事後討論的，但我認為若有約定，則為共識。既為共識，則宜立為指引，因此對於虛構事物已有約定，則為共識。既為共識，則宜立為指引又何嘗不可，當然維基百科也需要一個通用列表的關注度，我認同維基百科也需要一個通用列表的關注度，這可以是下一個階段的討論要點，但我仍然認為目前這個指引草案升級成為指引是沒有任何問題的，維基百科不是法院，而大量相關條目編者取得了共識也是事實，目前有問題要解決盾之勇者成名錄角色列表爭議問題需要解決也是事實，五個月有了共識也是事實，Cwek也提到缺乏相關規範導致改善卻步也是事實，我們又何嘗不試試這個指引? 相信這個指引立為指引對維基未來發展絕對是有所幫助的，以上。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月25日 (四) 16:41 (UTC)
    • 此由蟲蟲飛回應的小節，由於已經逾兩周沒有發表其他意見，因此此小節視為有初步共識，暫時作結。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月9日 (五) 07:03 (UTC)

如果對其他小節，如上方時間戳2019年7月16日 (二) 06:36 (UTC)等其他小節有其他意見仍可提出討論。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月9日 (五) 07:03 (UTC)

小節

目前討論狀態：

清理愛好者內容 無共識。盾之勇者存廢討論[討論已關閉] 进行中…提議設立愛好者內容改善流程 完成：愛好者內容提刪方式 已通過：愛好者內容30天提刪流程[討論已關閉] ↴ 先討論：完成「愛好者內容收錄限度」 結以待續：愛好者內容收錄限度[討論已關閉] 已通過：ACGN類[討論已關閉] 完成：主角定義問題[討論已關閉] 已通過：數理化類[討論已關閉] 無共識。計算機科學類[建議5-6月討論] 無共識。各大列表類[建議5-6月討論] 無共識。其他類型[討論已關閉] 其他議題： 进行中…：將關注度 (虛構事物)立為指引 無共識。：將日本ACGN故事簡介立為指引 不通過：設立愛好者內容轉移到第三方Wiki的制度[討論已關閉]

--宇帆（留言·歡迎簽到R₁R₂NKC） 2019年3月1日 (五) 14:10 (UTC) (更新) -- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月25日 (四) 16:02 (UTC)

提議本頁升為指引，命名部分似乎已有共識，但目前爭議例如《關於獨立虛構事物、跨媒體改編作品之列表的分割》則類似於WP:關注度 (性質表)一樣，規範著某個列表是否有關注度、是否有收錄/獨立條目必要，可以做為關注度指引的子指引，即，它規範著獨立虛構事物、跨媒體改編作品之列表的收錄準則，收錄準則應可以視為與關注度相同，用來規範一個條目可不可以存於維基；其餘說明為了指引完整性應予以保留，類似請參見WP:關注度 (幾何圖形)、WP:關注度 (性質表)等。各位認為如何？如果不認可，是否再立「關於獨立虛構事物、跨媒體改編作品之列表的收錄準則」（不推薦此法，要立太多規則，認為《關注度 (虛構)》是簡明最佳解）。我們需要解決Wikipedia:頁面存廢討論/記錄/2019/02/17#盾之勇者成名錄角色列表所點出的問題，畢竟已經花了五個多月了，一直在關注度議題上製造不同維基之最是不好的。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月19日 (五) 08:35 (UTC)

• 此案即日起公示七日及更名。산모사 ^DC17_{FLC GAC} 2019年7月21日 (日) 13:49 (UTC)
• 意见同上，只支持"收录标准"，其他部分不支持。~ viztor ✪ 2019年7月21日 (日) 14:11 (UTC)
  • @Cwek：。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月21日 (日) 16:40 (UTC)

@viztor：，对于虚构事物的处理方法的部分特殊性及关于涉及如何处理分割同样重要。你的意见，恕不苟同。——路过围观的Sakamotosan | 避免做作，免敬 2019年7月22日 (一) 00:28 (UTC)

• 「虛構事物列表收錄準則」亦是一個重要的收錄準則，需要作為關注度的一部分，規範「虛構事物列表受否該獨立條目」。而且也是前五個月的討論要點之一，不應否決。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月21日 (日) 16:38 (UTC)

公示期爭議

• 反对在WP:独立列表不是指引的情况下，打包夹带小指引。~ viztor ✪ 2019年7月22日 (一) 05:50 (UTC)
  • (！)意見WP:資料頁是指引。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月22日 (一) 05:59 (UTC)
    • (？)疑問@Cwek：是否把WP:独立列表拿掉，只留WP:資料頁？-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月22日 (一) 06:23 (UTC)

@A2569875、viztor：，相关链接已移除，我认为此问题已解决？——路过围观的Sakamotosan | 避免做作，免敬 2019年7月23日 (二) 03:01 (UTC)

• WP:独立列表與WP:关注度 (虚构)現階段並無關聯，大指引未通過不代表小指引不能通過。我不認為viztor的反對有效。산모사 ^DC17_{加泰隆尼亞圖書館GAN} 2019年7月25日 (四) 14:52 (UTC)
  • 通常来说，小指引需要解决大指引没有覆盖的特殊情况，在没有大指引的情况下，直接立虚构事物拆分的细则违背了立法原则。~ viz ✪ 2019年7月25日 (四) 15:21 (UTC)
    • WP:資料頁是指引，認為沒有問題。你的意見，恕不苟同。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月25日 (四) 15:49 (UTC)
• 我們需要解決Wikipedia:頁面存廢討論/記錄/2019/02/17#盾之勇者成名錄角色列表所點出的問題，勿繼續違背本案宗旨，畢竟已經花了五個多月了，相關問題可以再討論，但我認為此案升為指引沒有問題，繼續煮並無益處，我可不想再看到七萬字（目前已經快要一萬字了），且不是指引的部分已移除。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月25日 (四) 15:43 (UTC)
  • 诉诸情感~ viz ✪ 2019年7月25日 (四) 15:50 (UTC)
    • 目前的提案可以解決Wikipedia:頁面存廢討論/記錄/2019/02/17#盾之勇者成名錄角色列表所點出的問題，且不是指引的部分已移除，在沒有更好的方案下恕不支持你的觀點。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月25日 (四) 15:58 (UTC)
      • 相關問題可以再討論，但我認為此案升為指引沒有問題。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月25日 (四) 16:01 (UTC)
• 盾之勇者成名錄角色列表是甚麼問題呢，非百科內容?我並不這麼認為。當時為何會這麼提刪? 因為有一段論述這樣寫「若本章節過於龐大，請檢視並清理不必要的細節。之後將本章節整個以新條目分割，並且明記編輯摘要以符合版權協議。分割出的條目名稱建議設為「○○角色列表」（○○為作品名稱）。分割後原處應該有概要或簡列數名主要角色訊息。獨立列表請參見Category:虛構角色列表。」而新手在不明白的情況下建立了盾之勇者成名錄角色列表但問題來了，為什麼說是問題呢?因為當時這些相關內容不是指引，而該新用戶也只是單純地將原本位於盾之勇者成名錄的內容給獨立出來的，

由於缺乏相關收錄準則，甚麼是收錄準則，其實可以視為一種關注度準則，但由於缺乏相關收錄準則，因此對於能否收錄出現了極大爭議，且不止一次，這個並非兩三句話就能讓新手明白，因此我們花了四個月立了一個資料頁指引，亦即給出IINFO的最大限制，超出限制後就是IINFO可以提刪，但提刪前可以有一段緩衝期檢視是否可以將內容根據某個準則縮短成符合社群能接受的樣子，當然如果寫的是「要有現實世界影響內容」「加上評論, 開發過程,etc」「不要幾萬bit完全寫劇情」是沒甚麼爭議，但顧及內容完整性我們必須訂出哪些是維基百科需要的內容而哪些不是，不是的可以移除，等等，獲得了共識之後立了WP:資料頁他跟獨立列表的差別在於，WP:資料頁所列的內容若不符WP:資料頁準則則可以整個視為IINFO。 接著就是Temp3600所提出的「請問目前指引出那一條可推導出「盾之勇者成名錄角色列表應合併回主條目」?我覺得目前這部分描述不太清晰。角色列表，世界觀列表是否必須有獨立的關注度?我個人則認為這兩者是關注度可繼承自主條目的特例，所以我上面不要求存在獨立的第三方來源。但是，支持獨立列表的最低來源要求又是什麼呢?」

那麼這時我們需要特化的關注度指引，於是此案列於該案臨時動議，我並不認為目前這樣叫做沒有共識。在舊的存檔下，有十分多主編ACG的用戶參與討論，我們討論出了一套社群基本上能接受屬於虛構事物在還沒到IINFO之前的收錄準則，而這個收錄準則就是目前這個指引，我問為目前共識已足，如果已經有規範立為指引未見不妥，其他用戶便可以參照此指引完善相關條目，可見對維基百科是有益的，當然你點出的問題是可以事後討論的，但我認為若有約定，則為共識。既為共識，則宜立為指引，因此對於虛構事物已有約定，則為共識。既為共識，則宜立為指引又何嘗不可，當然維基百科也需要一個通用列表的關注度，我認同維基百科也需要一個通用列表的關注度，這可以是下一個階段的討論要點，但我仍然認為目前這個指引草案升級成為指引是沒有任何問題的，維基百科不是法院，而大量相關條目編者取得了共識也是事實，目前有問題要解決盾之勇者成名錄角色列表爭議問題需要解決也是事實，五個月有了共識也是事實，Cwek也提到缺乏相關規範導致改善卻步也是事實，我們又何嘗不試試這個指引? 相信這個指引立為指引對維基未來發展絕對是有所幫助的，以上，感謝你對我認為我情緒勒索的指控，抱歉但祝編安，但我仍然不認為此案升格為指引有任何的不妥。維基人張宇帆A2569875敬上-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月25日 (四) 16:34 (UTC)

上文所引用的WP:關注度 (幾何圖形)、WP:關注度 (性質表)都是自己主笔，通过自我引用来论证自己的合理性？为什么要在所有的地方复制粘贴完全一样的说明？为了保证统一性，你是不是要把这段文字复制到所有的关注度中？

你所引用的几则一样是你主笔。但实际上，列表是否分立本身即不是关注度的考虑范围。关注度定义的问题是什么？维基百科的关注度定义的对象向来是主题，topic。列表是某一主题相关内容的一种展现形式。是否独立为列表与关注度本身毫无半点关系。如果这个问题都不能理解，我不确定你是否知道自己在写什么。如果认为为了解决问题可以抛弃关注度的根本定义，那根本是本末倒置。是否分离为独立列表的问题是一种内容的组织形式问题，并非是”是否收录“的问题。

列表的收录与否，完全的取决于其主题是否应当收录。如果这个问题都没有厘清，就贸然动笔，是不可取的。复制粘贴别处的内容，并辩称其他自己写的都有，所以也要复制粘贴，本身是一种极糟糕的写作形式。此处不展开。请合理运用链接。~ viz ✪ 2019年7月25日 (四) 18:48 (UTC)

@Cwek、Temp3600、Sanmosa：不為別的目的，只為此案通過，另WP:關注度 (幾何圖形)、WP:關注度 (性質表)目前是指引，這是一個事實。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月25日 (四) 18:53 (UTC)

即便被学术期刊收录，也通常不鼓励自我引用。同一个糟糕的写法被重复50遍，也不会因此变好。~ viz ✪ 2019年7月25日 (四) 19:18 (UTC)

对人不对事，指引是谁写和允许谁引用并无直接关联，而且指引的内容意味经过社群的讨论而确立的共识，或者实际上包含或记录了社群参与讨论的意见，那就就意味着是不是所有参与讨论者不能引用这些指引？——路过围观的Sakamotosan | 避免做作，免敬 2019年7月26日 (五) 01:52 (UTC)

明明其他人写的都不会这样写，然后用自己的作品论证自己的合理性本身就是循环论证，所谓的共识，只是公示期无争议而已，没有人真的在意去看，或许如你所说是细节而已无足轻重的事情。不过把一个简单的东西肆意膨胀，写的不必要的长，无意识甚至刻意去重复一些早就说明的内容，用正确的废话占据近30%-50%的篇幅，本身就是有害的，现在你不觉得有差别，总有一天因为各种修改，这些东西互相之间变得不一样，那是不是要声称每个都重新煮一遍才能改？或许有些只是无人更新罢了，你是否要去维护？WP:KISS。~ viz ✪ 2019年7月26日 (五) 04:47 (UTC)

那就请去鄙视Wikipedia:關注度_(書籍)吧，作为最早一个的细项关注度指引。至少我认为所谓重复的章节，仍然相当合理，而一些必要的章节我看不出有什么修正。只能说大家的想法有所差别，而贵的异于常人罢了。——路过围观的Sakamotosan | 避免做作，免敬 2019年7月26日 (五) 07:04 (UTC)

书籍写的不知道高到哪里去了。~ viz ✪ 2019年7月26日 (五) 12:56 (UTC)

「關於條目分割後的關注度問題，其實暫時中文維基中還尚未出現一本著作因太長而分割。」 Wikipedia:關注度_(書籍)對應章節長這樣，囧。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月26日 (五) 14:14 (UTC)

• 「列表是否分立本身即不是關注度的考慮範圍」，不然改名叫做「列表收錄準則」好了。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月25日 (四) 19:09 (UTC)

其实逻辑是：大部分虚构事物列表或虚构事物独立条目是分割自对应的主体条目->但在没有资料页指引是，判断是按照关注度来处理的->而关注度当时的想法为以篇幅和讨论必要性来确定的->资料页指引确立的话，则确立了创建的要求和规范，也为了提供创建后的处理提供了合规性->我认为还是保留篇幅和讨论必要性作为一个关注度判断用于确定什么时候和如何去创建的前置条件，也保留再创建失败的情况下如何去收尾的操作（这也是该关注度的处理要求所给予的）。——路过围观的Sakamotosan | 避免做作，免敬 2019年7月26日 (五) 01:39 (UTC)

我的大意和Cwek一樣，而且現時討論中的主流共識也支持整體通過。산모사 ^DC17_{加泰隆尼亞圖書館GAN} 2019年7月26日 (五) 01:44 (UTC)

• 説什麼整個不是關注度，乾脆改名為「虛構收錄準則」算了，反正此案的命名在討論過程中也有出現爭議，而且此案本來就是用來決定某個虛構內容頁面能不能收錄的，另注意，維基有數個關注度指引是以「收錄準則命名」的。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月26日 (五) 02:20 (UTC)

(＆)建議：指引最重要的部分是「收錄標準」一節，大家似乎對此爭議不大，其他章節請U:A2569875可否根據大家意見修改？以求達成共識。--蟲蟲飛♡♡→♡℃※留言 2019年7月26日 (五) 03:38 (UTC)

(：)回應：@蟲蟲飛：這次草案不是我寫的，我不會改，我也不知道怎麼改，反正我不管寫什麼都會被嫌棄，問U:Cwek，認為需要解決盾之者問題。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月26日 (五) 03:49 (UTC)

刪除線。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月27日 (六) 22:02 (UTC)

：@A2569875：：其實誰寫沒關係，最重要誰想主持這個提案。簡單的做法是直接ping相關用戶，問他們想怎樣改，如果大家都想不到怎樣改，就刪去那一部分，留下那些大家共識的內容就可以了。--蟲蟲飛♡♡→♡℃※留言 2019年7月26日 (五) 03:55 (UTC)

既然大家都坚壁固守的话，该解释的我也解释过了，我也想不出还能达成些什么。（摊手）——路过围观的Sakamotosan | 避免做作，免敬 2019年7月26日 (五) 04:21 (UTC)

: @Viztor 、Cwek、A2569875：如果大家都想不到修改方法，不如把WP:虛構分割一個章節刪去？因為已經有相關的指引說明如何建立列表。請問大家有沒有異議？也請大家看看其他章節有沒有甚麼修改意見？蟲蟲飛♡♡→♡℃※留言 2019年7月26日 (五) 04:48 (UTC)

我有異議，這才是本次重點，解決盾之勇者存廢問題。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月26日 (五) 05:02 (UTC)

我已说明需要性，既然大家都坚壁固守，那就还能谈什么？——路过围观的Sakamotosan | 避免做作，免敬 2019年7月26日 (五) 04:53 (UTC)

• 如果這次沒有全部通過，我打算在這類繼續展開追加討論，我們需要解決Wikipedia:頁面存廢討論/記錄/2019/02/17#盾之勇者成名錄角色列表所點出的問題，繼續討論虛構列表收錄準則，直到達到共識為止。準備繼續討論半年吧。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月26日 (五) 05:10 (UTC)
• (！)意見請非涉事的維基人看看怎麼結案吧，該解決的問題還是得解決。關注度是收錄準則的一部分，雖然虛構列表收錄準則是「收錄準則」但它似乎已經超出關注度的範圍。 關注度對應的應是主題，而：列表（羅列同主題事物）、資料頁（羅列主題資料）、概述（如病毒入門）、條目（...就字面上的意思）...僅是對於某主題的百科呈現方式，當一個主題符合關注度，對應的列表、資料頁、概述、條目等都應具關注度，虛構事物問題在於，OO有關注度但OO事物列表並一定有關注度，因為兩者主題不同，例如《盾之勇者成名錄》有關注度，那麼盾之勇者成名錄角色列表存廢可能盲點是，該條目的主題是「盾之勇者成名錄角色」而不是「盾之勇者成名錄作品本身」，所以現在問題轉移成，不應探討「一個列表有無關注度」，而是「一個列表所述主題」有無關注度。現在所謂虛構拆分列表要探討的不是作品本身有無關注度，而是該列表所述實體的集合有無關注度，前五個月討論方向有些偏掉，又無人點出盲點才會到現在出現異議難以結案的窘境，首先感謝U:viztor點出盲點，另外也抱歉之前沒先看清楚就開始質疑，而且還是雜亂無論點質疑，抱歉。總之各方(包括我)先花些時間冷靜下來，再來看看接下來如何討論取得共識吧。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月26日 (五) 13:21 (UTC)

虛構列表收錄準則

籌備中。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月26日 (五) 05:45 (UTC)

現行條文 同理，我們通常不建議都為每一個獨立的虛構事物（如：人物角色、章節、場景），或某個作品系列的特定跨媒體改編作品都建立派生出的獨立條目，除非其符合關注度的要求，並且避免只是關於虛構作品的情節介紹。

提議條文 同理，我們通常不建議都為每一個獨立的虛構事物（如：人物角色、章節、場景），或某個作品系列的特定跨媒體改編作品都建立派生出的獨立條目，除非其符合關注度的要求，並且避免只是關於虛構作品的情節介紹。 同時，我們需要確保拆分列表的主題具有關注度，由於拆分列表的主題不會跟原主題相同，因此關注度不能繼承自原主題（如：「XX作品」具有關注度，並不意味著「XX作品的人物角色」具有關注度），而一個列表收錄的項目並非單一虛構主題實體，屬於一個虛構主題實體的集合，對於一個虛構主題實體的集合的關注度規範如下： 在一個虛構主題實體的集合中，至少需要有2項子主題符合WP:虛構準則或本身具關注度 例如貓咪大戰爭具有關注度，但由於貓咪大戰爭中沒有一項角色符合WP:虛構準則、也沒有一項角色符合關注度，根據此準則「貓咪大戰爭的角色集合」不符合關注度，因此應避免收錄貓咪大戰爭角色列表，但可以以少量篇幅於主條目介紹。 另一個例子哆啦A夢有多樣道具符合WP:虛構準則甚至有些有獨立於主題實體專題報導，因此根據此準則「哆啦A夢的道具集合」符合關注度，因此哆啦A夢道具列表可以獨立，但仍需注意篇幅、避免瑣碎資訊。 另外在該集合中符合關注度或虛構準則的子主題必須至少有一項與該集合主題有直接關聯。 例如，‎有尾巴的神奇寶貝中，皮卡丘符合關注度，但由於皮卡丘有關注度的原因明顯與皮卡丘有尾巴無關，因此，有尾巴的神奇寶貝不應獨立成一個列表。

• 以上提議@蟲蟲飛、cwek、Sanmosa、viztor：不曉得各位覺得如何？-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月27日 (六) 08:04 (UTC)
  • 我覺得可以。沒問題的話，其實可以兩者一同通過。산모사 ^DC17_{GAN FLC} 2019年7月27日 (六) 08:09 (UTC)
    • (：)回應U:Sanmosa由於是在公示最後一天加的，因此可能需要延長公示期為妥。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月27日 (六) 08:13 (UTC)
      • 沒錯。先把現在的公示撤下吧，待這裏有共識才一同公示。산모사 ^DC17_{GAN FLC} 2019年7月27日 (六) 08:17 (UTC)

(＋)支持:修訂版詳細多了，但有一處筆誤：「「XX作品具」有關注度」--蟲蟲飛♡♡→♡℃※留言 2019年7月27日 (六) 09:07 (UTC)

• 剛才看到帶着智能手機闖蕩異世界。裏世界角色列表，想到，假設有人找了2個可能有關注度的裏世界角色來說裏世界角色列表也要收錄的奇怪情形。因此我多補了一個條件，@Sanmosa、蟲蟲飛：你們看看行不行。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月29日 (一) 16:33 (UTC)
  • (～)補充上述條目已刪除，見Wikipedia:頁面存廢討論/記錄/2019/07/23#帶着智能手機闖蕩異世界。裏世界角色列表。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月6日 (二) 08:24 (UTC)

延長公示期討論

• 準備中。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月27日 (六) 08:20 (UTC)
  • (：)回應U:Sanmosa已暫停公示，請協助在適當的時機展開延長公示期。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月27日 (六) 08:36 (UTC)
• 如果其他人對最新處理沒有合理異議的話，我就會公示。산모사 ^DC17_FLC 2019年7月30日 (二) 01:06 (UTC)

(＋)支持:修訂條文不錯，感謝修訂﹗--蟲蟲飛♡♡→♡℃※留言 2019年7月30日 (二) 03:52 (UTC)

補充一下，新加入的準則是怕有人連一些奇怪的列表也說有關注度，例如《魔法少女小圓中，沒有頭的角色列表》之類的^{[開玩笑的]}。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月31日 (三) 09:40 (UTC)

(？)疑問，在前段已经确立了基于篇幅和讨论原则（“所以建议分割前，应先考虑是否需要进行清理，并请参照相关同类事物的列项内容与所占主题条目的内容过多时才考虑列表分割，并分割前需要进行讨论（包括但不限于：相应的虚构作品条目讨论页）。”），那是否需要保留这些原则？对于新增规则，暂无异议。——路过围观的Sakamotosan | 避免做作，免敬 2019年7月31日 (三) 04:23 (UTC)

• (：)回應我是因為您有表達過您認為該段落有一定的重要性，再加上目前討混的癥結點其一是「缺乏準則」以及「該段當前問題是『內容非關注度準則』」，因此添補了關注度準則，若無異議，本準則可以視為反映共識，並您提及的那串原有文字，我認為可是視為相關關注度準則的前言。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月31日 (三) 09:34 (UTC)

建议直接确立WP:独立列表。~ viz ✪ 2019年8月1日 (四) 22:07 (UTC)

由於此處的討論時間跨度已經跨到第七個月份 (2~8月)，時長也將近半年了，因此認為有共識的部分可以先結案，當然WP:独立列表也很重要，這將會是下一個階段要展開的討論。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月2日 (五) 01:58 (UTC)

@viztor、A2569875：独立列表需要另外花费时间来处理，既然这里产生了特例的话，可以优先这里处理。Wikipedia:格式手冊/列表、WP:资料页都有确立指引的。——路过围观的Sakamotosan | 避免做作，免敬 2019年8月2日 (五) 03:40 (UTC)

近期會開始籌備獨立列表的討論。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月2日 (五) 02:36 (UTC)

没看到特殊性。~ viz ✪ 2019年8月2日 (五) 10:47 (UTC)

主題==角色子集合﹑虛構事物集合等集合的關注度。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月2日 (五) 11:00 (UTC)

當然WP:独立列表也很重要，這將會是下一個階段要展開的討論。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月2日 (五) 11:03 (UTC)

近期會開始籌備獨立列表的討論。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月2日 (五) 11:03 (UTC)

• 如果新修訂的條文沒有異議，將會在適當的時間點寫進草案，並再找適當的時間點先公示Sanmosa說的「主流共識」。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月9日 (五) 06:55 (UTC)
  • 從討論時長來看，討論將在三天後期滿半年（2月16日~8月16日，換句話說 即此討論在Wikipedia:互助客栈/方针中已經放置半年，且未存檔過），預計在該時刻將新修訂的條文寫進草案，並預計在該時刻的一周後公示Sanmosa說的「主流共識」。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月13日 (二) 07:40 (UTC)
    • Special:Diff/55317432/55665407已經做好草案重新公示前的準備了，看閣下要不要找一個適當的時間開始進入延長公示期。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月15日 (四) 14:02 (UTC)
• 即刻起進入延長公示期，為期一周，到東八區時間2019年8月26日下午六時三分止，若期內無合理異議則升為指引。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月19日 (一) 09:59 (UTC)

針對列表的收錄準則

關於列表的收錄準則，各位有甚麼看法，借用en:Wikipedia:Notability#Stand-alone_lists是否可行？（此為英文維基中《獨立列表的關注度》）-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月2日 (五) 12:23 (UTC)

• 已逾十天無人討論。如果大家都不想討論，我建議有共識之處先通過，存檔後，再開啟新討論。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月13日 (二) 07:47 (UTC)

將Wikipedia:重定向升為方針

本討論承接Wikipedia_talk:重定向/存檔4#將WP:重定向提升為指引或方針。산모사 2019年7月4日 (四) 11:29 (UTC)

在下閱讀全篇內容未見不妥之處，提議立即將整個WP:R確立為指引或方針，促進關於WP:RDRNC的建設性討論。

歡迎大家發表意見，但請不要提到WP:RDRNC。話說有人注意到其實是抄自Wikipedia_talk:重定向#將WP:重定向提升為指引或方針嗎？-- Sunny00217 - 2019年7月1日 (一) 11:26 (UTC)

这是要延续之前被存档的那个讨论吗？上一次是提出了一些修改意见的，见《Wikipedia_talk:重定向#將WP:重定向提升為指引或方針》。Cswquz（留言） 2019年7月1日 (一) 18:16 (UTC)

能不能把那些修改意見都copy過來？我同意延續。Σανμοσα 2019年7月4日 (四) 07:02 (UTC)

见Wikipedia_talk:重定向/存檔4#將WP:重定向提升為指引或方針.--Cswquz（留言） 2019年7月4日 (四) 09:08 (UTC)

那個討論較長，我索性加個頂註說是延續既有討論就好。산모사 2019年7月4日 (四) 11:29 (UTC)

• 把不刪除的原因「應該避免刪除」改為「建議保留」，表明並非強制，常識仍然適用，避免有人繼續扯皮。-- Vakrieger♀︎ (💢❤️🗯️) 2019年7月7日 (日) 09:55 (UTC)
• 我認為條文中刪除理由第三項、不刪除理由第五項、WP:NOTBROKEN，以及WP:RDRNC明顯還需要討論，解決了這幾個問題就可以提案升格：
  1. 刪除理由第三項：「冒犯性」的定義需要詳細闡明；
  2. 不刪除理由第五項：「有用的重定向」的去留需要深入討論，我肯定有人對於這個條文有反對；
  3. WP:NOTBROKEN：應該加入條文說明「不應該修改，但修改不是不可以；不用回退修改」；
  4. WP:RDRNC：如果全數保留「有用的重定向」，那樣由於WP:RDRNC的重定向全部都是「有用的重定向」，條文可以廢掉／融入至其他部分；如果並非，則外文重定向的去留範圍需要詳細討論，因為根據之前的討論，不同人對於這個範圍有非常不同的意見；
• 以上；@Vakrieger、Cswquz。산모사 ^DC17 2019年7月10日 (三) 09:41 (UTC)
  • 關於「冒犯性」那個，我覺得重定向方針可以不提這個，直接用速刪解決。（重定向都那麼短小，如果有冒犯性肯定是「明顯」啦）
  • 至於「有用」，我覺得可以保留，反正這個只是指導意見，並非強制
  • 以上兩點可能存在爭議或者衝突（比如那個「思歪」），在下認為是否刪除，應以「是否原創」劃界（也就是如果這個重定向的別名是已經廣泛使用，且有可靠來源支持的，就保留；如果是維基人自創的，就刪除）-- Vakrieger♀︎ (💢❤️🗯️) 2019年7月10日 (三) 13:42 (UTC)
    • User:Vakrieger我在「冒犯性」那一項註明了以可靠來源作為判斷標準，另外也同意閣下「有用」只是指導意見的看法（應該避免≠必須避免）。但仍想請問閣下對於我對WP:NOTBROKEN的意見有何看法？산모사 ^DC17 2019年7月11日 (四) 06:02 (UTC)
• User:Sanmosa 關於not broken，我覺得條文本意是提醒編者替換連結是沒有必要的，並沒有說禁止這麼做，所以沒必要加上那一句。我擔心如果加上那一句，反而讓條文失焦。-- Vakrieger♀︎ (💢❤️🗯️) 2019年7月12日 (五) 02:26 (UTC)
  • User:Vakrieger但過去有先例是有用戶認為等於禁止。산모사 ^DC17 2019年7月12日 (五) 09:07 (UTC)
    • User:Sanmosa那可以加入條款表明不必回退。但為了平衡，我建議增加一句「反覆建立此類連結的用戶，應該進行提醒」。如果用戶不管提醒繼續修改，算不算破壞？我覺得應該按常識處理，條文不必指明。-- Vakrieger♀︎ (💢❤️🗯️) 2019年7月12日 (五) 13:04 (UTC)
• 基本上除了RDRNC以外，整個方針就沒甚麼大問題了。我建議上方動議修改RDRNC的討論有定案後，再一併通過整個方針。산모사 ^DC17 2019年7月15日 (一) 09:17 (UTC)

重譯提議

(＆)建議 这篇指引草案WP:R基本上是从英文早期版本翻译过来的，再加上中文维基独有的WP:RDRNC. 演变到目前，英文版en:WP:R源代码已达36K，中文版只有16K. 所以建议整篇重译，再去掉不适用于中文维基的以及整合上现有的条文。--Cswquz（留言） 2019年7月14日 (日) 11:11 (UTC)

• @Cswquz：在下建立了一個草稿在User:Vakrieger/Draft/WPRT，歡迎大家幫忙翻譯。-- Vakrieger♀︎ (💢❤️🗯️) 2019年7月15日 (一) 07:28 (UTC)
  • 我認為「整篇重譯」應視為長遠方案，而非現階段作為替代臨時方案的永久方案，而且應該要翻譯完成才提案方為正道。산모사 ^DC17 2019年7月15日 (一) 09:09 (UTC)

我才看到还有嵌入的代码段，包括《删除的理由》一节。那一节的英文代码有11K，而中文的目前是5.2K，所以如果加上这一节，则英文47K，中文21K. 而且我前些天所试译的几句已经被加进中文草案：[2]，但这里有问题：我当时重译的这一条只适用于英语维基，如果是中文维基，则除了原文以外，还应允许建立英文译名或拉丁转写的重定向（如果原文非英文乃至非拉丁字母）。--Cswquz（留言） 2019年7月15日 (一) 12:14 (UTC)

• 认同，翻译特别糟糕。第一句就看不下去。

一个重定向，是指一个页面没有自己的内容，但是将读者送到另外的页面，通常是一个条目或者一个条目的章节。

重定向是一类本身没有内容的页面，它们把读者送达到其他的目标（可以是条目或者条目的章节）。

对比。~ viztor ✪ 2019年7月17日 (三) 07:27 (UTC)

• 整篇重譯的草稿已移動至Wikipedia:重定向/20190720。我已經翻譯了一些，請各位幫助繼續翻譯和校對。在下(＋)强烈支持整篇重譯，然後直接通過為方針，不用管以前那個版本。 -- Vakrieger♀︎ -- 💢❤️🗯️ 2019年7月20日 (六) 07:22 (UTC)
• 「重定向的用途」和「刪/留理由」已經翻譯完畢，請各位發表意見。在下覺得這幾章如果通過，已經足以取代 RDRNC 章節（後者可以作為一個增補解釋單獨成篇）。-- Vakrieger♀︎ -- 💢❤️🗯️ 2019年7月25日 (四) 09:07 (UTC)

整篇重譯已經完成；請各位發表高見，並幫助編修、校對和維基化。-- Vakrieger♀︎ -- 💢❤️🗯️ 2019年7月30日 (二) 09:37 (UTC)

• User:Vakrieger和User:Cswquz我已經把經過微調的翻譯直接發佈在wikipedia:重定向頁面了，我建議把未通過為方針的條文全數通過為指引，惟「重新導向的中立性」則提升為方針。산모사 ^DC17_FLC 2019年7月31日 (三) 01:24 (UTC)

@Sanmosa、Vakrieger：Wikipedia:重定向#何时应当删除重定向？一直包括了一个嵌入子页面WP:重定向/删除的原因，但7月31日的那次修订可能是没注意到这一点。刚刚我已恢复原来的处理，详情见《重定向》及《重定向/删除的原因》的修订记录。另，我也独立将子页面《WP:重定向/删除的原因》从英文版重译了一遍，译稿见《WP:重定向/删除的原因/译稿20190803》，建议将原来的版本、最近的两种新译本作校订、整合。还有一篇维基百科:外文重定向，也建议译出并将现在正在讨论修订的方针《Wikipedia:重定向#非中文重定向問題》与之整合。--Cswquz（留言） 2019年8月3日 (六) 15:01 (UTC)

@Cswquz：我反而認為應該放棄原來子页面分立的做法。另外，我認為不需要再整合，閣下現在反而變成過度翻譯了。维基百科:外文重定向不建議翻譯，我建議改為用上面重做RDRNC的提案代替。산모사 ^DC17_{GAC FLC} 2019年8月3日 (六) 15:25 (UTC)

我头回听到“过度翻译”这说法。有相关论述吗？--Cswquz（留言） 2019年8月3日 (六) 16:24 (UTC)

@Sanmosa：我注意到足下将上述子页面又恢复混排了，我回退了该次编辑。关于设立这个子页面的可能的好处，我有一些个人理解，见User_talk:Wong128hk#WP:重定向的“何时删除重定向”章节一直就是用嵌入页面--Cswquz（留言） 2019年8月3日 (六) 16:43 (UTC)

• • (：)回應：取消子頁面分立是我翻譯時故意的做法，因為我覺得沒有必要，反而使編輯更為麻煩（英文版這麼做是因為這些在其他地方（比如重定向專門的提刪頁面）也有引用，我們沒有）。-- Vakrieger♀ 💢❤️🗯️ 2019年8月4日 (日) 06:48 (UTC)
  • 另外，在下不反對翻譯《外文重定向》，但是應該針對中文版的情況做一些改變（畢竟人家英文已經是廣泛使用的世界語言，地區譯名區別基本不存在，也很少有非官方譯名和原創譯名問題）。與之相比，我們對外文重定向會有更高的需求。在下覺得這裡的整篇翻譯版和上面的新 RDRNC 已經能較好地傳達英文《外文重定向》的精神。-- Vakrieger♀ 💢❤️🗯️ 2019年8月4日 (日) 06:52 (UTC)

@Vakrieger：我先前没仔细看，不久前才注意到英文版《外文重定向》只是一篇论述，在英文维基也尚未通过成为方针或指引。其中包含了诸多个人观点，未见得适当，且与中文维基的现实需求也颇有差异。只能说其中某些论述可供借鉴，整篇不译也罢。

再来是分立子页面的事情。我已在上述行政员讨论页又留言若干，大致意思就是在这个问题上我倾向于采取保守态度。事实上，我自己翻译时也是把子页面的代码整个拷贝进主页面进行的，但我一直压根就没想要把这作为今后的长期安排。--Cswquz（留言） 2019年8月4日 (日) 08:07 (UTC)

@Vakrieger：我已将子页面WP:重定向/删除的原因作了整合修订，并将代码拷贝到主页面。--Cswquz（留言） 2019年8月5日 (一) 23:12 (UTC)

差別討論

全篇翻譯後的《重定向》與中文版現行的一套有一些出入，在下希望聽聽大家的意見。-- Vakrieger♀︎ -- 💢❤️🗯️ 2019年7月31日 (三) 06:44 (UTC)

重定向保護

重定向保護方針原本是在翻譯件內的，但因為不符中文維基百科現狀被編輯移除了。內容如下：

具有以下情形的重定向可能會受到長期保護：

1. 沒有理由對重定向進行編輯，和/或
2. 它經常被擴展為整篇文章，和/或
3. 是一個明顯的破壞目標，和/或
4. 重定向和/或其目標容易挑起爭議

值得保護的重定向包括「奧巴馬」、「希特拉」、「傻逼」等。另外，十分常用之模板重定向也可能被視為高風險模板而被保護。

在下認為我們可以考慮採用。-- Vakrieger♀︎ -- 💢❤️🗯️ 2019年7月31日 (三) 06:44 (UTC)

Xiplus, 目前有对重定向保护的实践吗？~ viz ✪ 2019年8月1日 (四) 22:09 (UTC)

「沒有理由對重定向進行編輯」，這通常是因為剪貼移動等視為破壞的行為以破壞為原因保護，不會因為沒有理由編輯就保護。

「經常被擴展為整篇文章」，同前，或存廢討論為改為關注度重定向遭到撤銷等情事。

「明顯的破壞目標」，就是破壞保護。

「容易挑起爭議」，通常因編輯戰保護。

以上4項敘述在某部分正確，但明顯需要重寫。--Xiplus#Talk 2019年8月4日 (日) 01:20 (UTC)

• (※)注意：這個是英文版的現行做法，的確與我們的現行做法不同。我認為中文版應該趁這次修訂《重定向》新增這些做法，徵求大家的意見。-- Vakrieger♀ 💢❤️🗯️ 2019年8月4日 (日) 06:45 (UTC)
• 另外，英文版對這些重定向是預防性保護，不必已經出現破壞或編輯戰。-- Vakrieger♀ 💢❤️🗯️ 2019年8月4日 (日) 06:57 (UTC)
  • 我认为这可考慮。산모사 ^DC17_{GAC FLC} 2019年8月5日 (一) 01:11 (UTC)
  • 有什麼合理的理由可以預防性保護？--Xiplus#Talk 2019年8月5日 (一) 01:24 (UTC)
    • 我覺得保護頁面防止破壞的唯一負面影響是妨礙編者（至少是新手編者）改善條目。重定向條目在查證、標記完成後完全沒有改善空間（唯一的例外可能是目標頁面被移動，但重要目標條目不太可能會移動，就算移動可以輕易以管理員機器人解決），所以此理由不存在。我支持對可能有爭議的重定向進行至少半保護。-- Vakrieger♀ 💢❤️🗯️ 2019年8月5日 (一) 02:10 (UTC)
      • User:Vakrieger我不希望有人僅僅因「沒有理由對重定向進行編輯」為理由請求保護，按照保護方針這類請求會被拒絕，而且根據方針指引上下級關係，指引跟方針牴觸是遵從方針。--Xiplus#Talk 2019年8月15日 (四) 00:54 (UTC)
        • 把方針IAR掉就好，但認為不設立此規則也可。산모사 ^DC17_{FLN1 FLN2} 2019年8月15日 (四) 07:31 (UTC)

• 維基百科不墨守成規。如果對項目有好處，現有規則可以修訂甚至忽略。@Xiplus：想聽聽您為什麼「不希望有人僅僅因『沒有理由對重定向進行編輯』為理由請求保護」？-- Vakrieger♀ 💢❤️🗯️ 2019年8月15日 (四) 23:32 (UTC)

• User:Vakrieger我更想聽聽保護有什麼好處？--Xiplus#Talk 2019年8月16日 (五) 00:53 (UTC)

我对这一部分是这么理解的：因为《重定向》在英文维基是一篇指引，所以就把需要保护的情形中涉及到重定向的部分挑出来写成这一节。如上面某位所述，中文维基有时也会保护重定向页，只不过没有设立专门的页面来受理重定向页的保护请求而已。所以我的(＆)建議是：加上这一节，这不会对目前的实务造成多大改变。--Cswquz（留言） 2019年8月6日 (二) 07:22 (UTC)

貌似英文维基也并无专门页面来受理重定向页的保护。--Cswquz（留言） 2019年8月6日 (二) 08:04 (UTC)

• (＋)支持保護沒有明顯必要更動名稱的重定向--Z7504非常建議必要時多關注評選（留言） 2019年8月8日 (四) 16:34 (UTC)

@Vakrieger、Sunny00217、Xiplus：我把这章加回去了。另，本讨论串总标题是“将WP:重定向升为方针”，似应作“升为指引”。--Cswquz（留言） 2019年8月14日 (三) 16:49 (UTC)

@Cswquz：為甚麼不能直接成方針？難不成還要先成指引再成方針嗎？無法理解-- Sunny00217 2019年8月15日 (四) 08:19 (UTC)

老实说，我是刚刚知道“方针”高于“指引”。那么，《重定向》在英文维基是一篇指引；而且，上面已有围绕《重定向保护》的争论，如果是“方针”，强制意味更多，“指引”的话就可以作更宽松的理解，也就是不会要求目前的管理方式发生实质性的变更。--Cswquz（留言） 2019年8月15日 (四) 08:31 (UTC)

• 在我的理解下，「方針」(policy)更加注重管理方面的操作，而「指引」(guideline)主要旨在規範編者的行為方式；二者都受忽略所有規則的限制，沒有明確的從屬關係。這樣看來，《重定向》確實更適合成為指引。反正我覺得其實差別不太大啦-- Vakrieger♀ 💢❤️🗯️ 2019年8月15日 (四) 23:40 (UTC)

建議升為指引，成為方針似乎太過嚴厲。--Opky9407（留言） 2019年8月20日 (二) 10:07 (UTC)

我看過了一下，技術性的細節比較多，確實適宜設為指引，但「何時應當刪除重新導向？」的部分要升為方針，以防止部分濫（提）刪重定向。산모사 ^DC17_{FLN1 FLN2} 2019年8月20日 (二) 23:59 (UTC)

• (＆)建議：如果根據這條對重定向進行預防性全保護，應該授予現有的幾個修正雙重重定向的機器人例外權。-- Vakrieger♀ 💢❤️🗯️ 2019年8月15日 (四) 23:40 (UTC)

• 我考慮了一下，中文版的重定向破壞問題並不算嚴重，所以建議將本條文改為「以下情形的重定向，在管理員認為有必要時，可以（但不是必須）進行長期保護」，以免增加管理員的工作量。-- NSW VAK·RKS 💢❤️🗯️ 2019年8月18日 (日) 09:36 (UTC)

重定向分類

英文版原則上強制對重定向進行維護分類。當前中文版有全套重定向分類模板（rcat），但實際使用較少。在下覺得可以在方針中要求所有重定向均放入這些分類模板，讓讀者和其他編輯明白重定向的用途（反正也不麻煩）。可以只要求新的重定向適用此規定（若創建者沒有加入，可以請巡查員幫忙），已有的則慢慢補上。-- Vakrieger♀︎ -- 💢❤️🗯️ 2019年7月31日 (三) 06:44 (UTC)

• 我認為不一定要強制加入。산모사 ^DC17_{GAC FLC} 2019年8月5日 (一) 01:09 (UTC)
  • 改成「建議加入」如何？-- Vakrieger♀ 💢❤️🗯️ 2019年8月5日 (一) 07:06 (UTC)
    • 我覺得可以。산모사 ^DC17_{GAC FLC} 2019年8月5日 (一) 13:25 (UTC)
    • 還不錯的提議心平星辰（留言） 2019年8月7日 (三) 17:19 (UTC)
• User:Vakrieger重定向分類條文現在可以加進去嗎？還是已經加了？我打算日內公示，預定為指引，其中「何時應當刪除重新導向？」部分為方針。산모사 ^DC17_{FLN1 FLN2} 2019年8月20日 (二) 23:53 (UTC)
  • User:Sanmosa 支持將分類條文加進去公示，但建議考慮一下要不要先拿掉保護那一章。-- NSW VAK·RKS 💢❤️🗯️ 2019年8月21日 (三) 01:41 (UTC)
    • 我已微調相關條文至管理員可选择性执行重定向保护。산모사 ^DC17_{FLN1 FLN2} 2019年8月21日 (三) 02:29 (UTC)

有关IP封禁豁免权接下来的审发处理办法

下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

---

诸位好。目前管理员批予IPBE各自为政，没有统一的标准。我跟另一名管理员Xiplus就IP封禁豁免权的审发稍作了一些讨论。鉴于当前WP:IPBE的相当一部分内容都是在2015年5月中国屏蔽维基百科之前制定的，其中规定的一些做法已经不合时宜，确有必要重新讨论。在第一轮讨论时，鄙人先希望社群在两个大方向中择一，然后再讨论细节。

方案一：宽松

有人提出申请或管理员认为该用户有必要持有IPBE的，即予以发放。除非申请人指明只需要在某一期限内持有IPBE权限。

方案二：严格

管理员按照先给半年，之后一年一年地续地方式来批IPBE。

对于两个方案，还有值得注意地方是：

• 对于方案二，最明显的问题是给管理员和用户本身造成的麻烦。很多用户没法了解IPBE的运作机制（相信很多读这条讨论的人也不清楚，只知道“有了IPBE就能用”），突如其来的封禁会导致其丧失编辑兴趣，造成麻烦；管理员也需要多次赋权。另外，也会阻碍一些不频繁编辑的用户（比如说，一两个月编辑一次）参与编辑的成本。
• 目前中文维基上有一个机器人，会自动监视所有带有IPBE权限的用户。当该机器人发现某用户半年没有编辑时，会提报该用户到Wikipedia:申请解除权限中，再由管理员复核除权。这一机器人自动提报无编辑的带IPBE权限用户，跟提报无编辑的巡查员、回退员本质上是一个功能。这也就意味着，如果管理员直接批复无限期IPBE，但之后不活跃编辑，机器人会提报该用户，再由管理员手动除权（而非自动除权）。当然，机器人有调整设定的空间。

当然，具体机器人之后应该怎么调整（直接自动除权、不再提报带有IPBE功能的用户还是维持现状）都是后话，现在请各位集中讨论在“宽松”和“严格”两个大方向上。机器人和方针细节，在社群的总体意向敲定之后再做调整。

从我个人的立场上，支持较为宽松的方案。

• 虽然IPBE某种程度上作为跟巡查和回退一样的权限，可以在用户行为不端时移除（而非封禁），曾经也有一些管理员这样做过；但是因为移除IPBE等于事实上的封禁，所以通过限制IPBE来限制用户破坏不可行。
• 从我个人经验来看，没有遇到过获批IPBE的零星破坏者或LTA。
• 管理员注册的账号再直接给IPBE、续期IPBE，无论如何都不会留下用户真实的IP地址，对于CU来说，不会有任何优势。我们甚至不知道用户有没有用Tor，如果用了，那更完全没有办法CU。
• 机器人在六个月没有活动的情况下才会提报不活跃的用户，此时CU数据早已过期。

欢迎各位发表意见。

--Techyan（留言） 2019年7月1日 (一) 15:22 (UTC)；修改于2019年7月2日 (二) 06:19 (UTC)

• 支持「寬鬆」方案。我覺得 IPBE 可以無限期持有，不一定要每六個月編輯一次（或者說每六個月登入一次就好），方便不甚活躍的用戶。但還是需要有某種機制確認用戶的真實 IP，不然 IP 封禁形同虛設。具體點說，我覺得可以建立一個 web beacon 讓申請人用真實 IP 點擊（bit.ly 之類的都可以），確認用戶是否真的需要 IPBE（比如的確位於中國等），然後永久保存其真實 IP 的 hash，作反破壞之用。以上過程甚至可以用機器人完成。 -- Vakrieger♀︎ (💢❤️🗯️) 2019年7月1日 (一) 20:35 (UTC)
  • 反对任何方式的额外收集个人隐私。->>Vocal&Guitar->>_留言 2019年7月2日 (二) 01:15 (UTC)
    • (：)回應 用戶需使用真實 IP 註冊是維基媒體基金會的政策（不然為什麼原則上禁止開放代理），這不算是「額外收集個人隱私」。如果完全放開（即有人提出申請便自動批出），太容易被濫用（网络评论员之類）-- Vakrieger♀︎ (💢❤️🗯️) 2019年7月2日 (二) 04:50 (UTC)
      • 现在大部分被认为proxy地址全局封禁是禁止创建账户，可以迫使到其他项目上创建账户（因为其他项目可以直接访问，能记录真实地址），然后通过中央认证来本地，再授予IPBE。这是不能本地CU确定实际地址但有希望记录实际地址的比较迂回的方法。——路过围观的Sakamotosan | 避免做作，免敬 2019年7月2日 (二) 08:46 (UTC)
        • 這個辦法不錯，我覺得可以引導郵件詢問IPBE的用戶這樣註冊（但如果中國哪天決定封鎖所有維基媒體項目就得另想辦法了）。本地不能CU我覺得問題不是很大反正本地也沒有權限，還不是得上報，至少可以明顯增加大規模註冊帳號的成本（單個IP註冊太多會被限制的吧）-- Vakrieger♀︎ (💢❤️🗯️) 2019年7月2日 (二) 11:33 (UTC)
        • @Cwek：錯誤方法，禁止创建账户的封禁也會阻止自動建立帳戶，如此做反而會造成管理員更多的工作。--Xiplus#Talk 2019年7月2日 (二) 11:56 (UTC)
        • “可以迫使到其他项目上创建账户（因为其他项目可以直接访问，能记录真实地址），然后通过中央认证来本地”，复读一次。——路过围观的Sakamotosan | 避免做作，免敬 2019年7月2日 (二) 13:09 (UTC)
          • @Xiplus：他說的應該是用非代理IP在其他項目建立帳戶，不會被阻擋 -- Vakrieger♀︎ (💢❤️🗯️) 2019年7月2日 (二) 12:55 (UTC)
            • @Vakrieger：但在本地的時候不開代理無法存取，開代理無法自動建立帳號。--Xiplus#Talk 2019年7月2日 (二) 13:05 (UTC)
              • @Xiplus：這樣啊，我以為在一個維基項目建立帳號後，過段時間會自動在其他的也建立（我的CentralAuth裡面一大半都是我從來沒有訪問過的語言）。-- Vakrieger♀︎ (💢❤️🗯️) 2019年7月2日 (二) 13:12 (UTC)
                • @Vakrieger：這是在沒有被封禁的情況下，要不然如果可以自動註冊的話，封鎖IP禁止建立帳號不就沒有用處了嗎？--Xiplus#Talk 2019年7月2日 (二) 13:13 (UTC)
                  • @Xiplus：但是用非代理IP註冊其他項目（在中國可以直接訪問的），算是「沒有被封禁」吧？別再爭了，去試驗一下-- Vakrieger♀︎ (💢❤️🗯️) 2019年7月2日 (二) 13:16 (UTC)
                    • User:Vakrieger封禁基於站點，一個帳戶要在本地自動建立，就會受本地封禁影響（當然還有全域封禁）。--Xiplus#Talk 2019年7月2日 (二) 13:43 (UTC)
        • 在其他维基项目上创建账号不是一个好主意。CU记录只能留三个月，且只有一条记录，利用参考价值都不高。另外代理IP也不是不能查，知道怎么回避CU的无论如何都不会被查出来，不知道怎么回避CU的用代理也一样能查。让用户去其他语言wiki注册，除了暴露不必要的隐私之外没有别的用途。编辑都是用代理做的，去查他本身IP没有价值。现在CU转移到元维基，那边的人反而更少依赖GeoIP来给出结果。另外，说服监管员去查global也不容易。--Techyan（留言） 2019年7月3日 (三) 02:05 (UTC)
• 支持寬鬆方案。—— Eric Liu_{（留言．留名．學生會）} 2019年7月2日 (二) 03:06 (UTC)
• 支持宽松，反正CU核查速度这样慢，没查也没关系啦，但中文维基一旦拿回权限，就停止宽松。--Cohaf(talk) 2019年7月2日 (二) 03:48 (UTC)
• 可以按照用户权限给予，先期6个月，6个月复核编辑数量后再追加至1年，1年后复核再给予不限期。有参与管理型工作（例如巡查、回退）可以直接给无限期。——路过围观的Sakamotosan | 避免做作，免敬 2019年7月2日 (二) 08:49 (UTC)
• 反对给IPBE要CU的做法，任何时候都反对--百無一用是書生 (☎) 2019年7月3日 (三) 02:25 (UTC)
• 看來不少人認為真實IP是私隱。考慮到中國網絡都是實名制，我現在理解安全上的擔憂，不再贊成上述驗證真實IP的要求。如果有人感到冒犯，我表示十分抱歉。但我還是不贊成完全無條件授予IPBE，讓IP封禁形同虛設。這方面社群必須做出一個平衡取捨。 -- Vakrieger♀︎ (💢❤️🗯️) 2019年7月3日 (三) 07:57 (UTC)
• 就以我個人處理上，會要求正在使用的代理IP，以確認是否真的被封禁、是否真的需要IPBE。--Xiplus#Talk 2019年7月3日 (三) 14:17 (UTC)
• 從本地還有CU的時代開始，似乎就很少執行過WP:CUP#3（授予IP封鎖例外前，進行檢查），未來應該也會如此；本串討論重點應在於授予期限而已，而非是否授予，也無關於CU等問題了。--Xiplus#Talk 2019年7月3日 (三) 14:21 (UTC)
• 一次授予长期权限（“宽松”）在机器人持续工作的情况下，和只授权半年没什么区别。但考虑到一些罕见情况，长期授权之前，申请者至少应该给出他被封禁的证据，例如封禁界面显示的文字（包含涉及的 IP 段，自己的代理 IP 地址等）。一些站外教程有些误导，也有人看了教程就发邮件，也不知道自己在做什么。目前的网络条件下，IPBE 广泛授权没问题；真正的 LTA 就算 CU 也还是成天来捣乱。不过我不觉得这个权限可以“极其随意地”授予。--Tiger（留言） 2019年7月4日 (四) 01:56 (UTC)
• 傾向方案1，但是我希望條文能夠寫得更明確。建議條文如下：

“ 凡有人申請即可予以發放；除非申請人指明只需要在某一期限內持有IPBE權限，否則權限永久。另外，管理員認為該用戶有必要持有IPBE時，即使該用戶未有申請，也可授予其臨時或永久權限；被授予臨時權限者可申請延長時限或永久權限。 ”

以上。Σανμοσα 2019年7月4日 (四) 07:11 (UTC)

• 條文似乎矛盾？前文說有人申請即予以發放，後文有說是管理員認可才發放？--【和平至上】💬📝 2019年7月4日 (四) 09:44 (UTC)
  • User:和平至上我微調了一下。산모사 2019年7月4日 (四) 23:57 (UTC)
• (＋)支持 這個提案，符合社群共識。-- Vakrieger♀︎ (💢❤️🗯️) 2019年7月5日 (五) 07:23 (UTC)
• 「凡有人申請即予以發放」是不需審核即授予嗎？那乾脆弄機器人算了。--Xiplus#Talk 2019年7月5日 (五) 09:04 (UTC)
  • 还是得要人工把关。现在IPBE的需求量没有那么恐怖。--Techyan（留言） 2019年7月5日 (五) 13:08 (UTC)
  • User:Xiplus和User:Techyan我再微調了一下：「即可予以發放」，管理員還是有不發放的酌情權的。산모사 2019年7月5日 (五) 13:19 (UTC)
    • 意思沒變啊，而且本提案僅是關於期限的諮詢，根本沒必要動到任何方針指引。--Xiplus#Talk 2019年7月5日 (五) 13:24 (UTC)
• 個人是支持憑封鎖ID或是被封鎖的IP拿權限。--Hamish歡迎來訪 2019年7月6日 (六) 14:44 (UTC)

讨论到最后，肯定是会去修方针指引的，只不过现在还没到时候。上面的讨论似乎还没什么共识，希望大家把自认为最好的处理方法都讲出来。过几天开始下一阶段的讨论。--Techyan（留言） 2019年7月7日 (日) 14:21 (UTC)

• 我看到社群主流的傾向都是寬鬆方案，我建議可以就此作下一階段的討論，在那時才詳細討論細節。산모사 ^DC17 2019年7月10日 (三) 10:01 (UTC)

宽松方案的具体细节

重新总结了上面的讨论。宽松方案，即“有人提出申请或管理员认为该用户有必要持有IPBE的，即予以发放。除非申请人指明只需要在某一期限内持有IPBE权限”，如果没有问题，那么这一条就要实行下去了。除此之外，还需要制定方针，要求当具有IPBE的用户因故封禁时，不得移除其IPBE权限；不得通过移除IPBE权限变相封禁用户。这一点我会写入WP:BLOCK和WP:IPBE中。另外，若要实施宽松方案，那么还有一个问题没有解决，即是否应该让机器人停止提报半年没有活动的IPBE用户。

有关机器人的问题，摘录上方提案：目前中文维基上有一个机器人，会自动监视所有带有IPBE权限的用户。当该机器人发现某用户半年没有编辑时，会提报该用户到Wikipedia:申请解除权限中，再由管理员复核除权。这一机器人自动提报无编辑的带IPBE权限用户，跟提报无编辑的巡查员、回退员本质上是一个功能。这也就意味着，如果管理员直接批复无限期IPBE，但之后不活跃编辑，机器人会提报该用户，再由管理员手动除权（而非自动除权）。

欢迎各位就机器人的处理问题发表意见。除了机器人之外，可能还有其他需要细节，欢迎各位补充本提案。

--Techyan（留言） 2019年7月12日 (五) 00:47 (UTC)

封禁方面的问题，不知是否有“通过移除IPBE权限变相封禁用户”的案例？按照现行条文来说，除权须有滥用权限的情形。如果没有滥用 IPBE，按照规定本来就不该除权。我看到不少短期封禁以后，用户被机器人提报到除权请求，结果是因封禁原因与 IPBE 无关而不除权。只有少数，封禁原因是滥用傀儡的，才除去 IPBE，且一段时间内因其滥用傀儡的记录不授予 IPBE。不知这种除权是否有什么问题？--Tiger（留言） 2019年7月12日 (五) 01:44 (UTC)

那我修改一下措辞：除非用户有滥用傀儡等明显不应继续持有IPBE的情况，否则不得只因封禁除权；不得通过移除IPBE权限变相封禁用户。后者的情况，我记得很久之前是在解除权限里讨论过一段时间，最后不知道怎么了，但是的确发生过某持IPBE的普通用户因故封禁，然后管理员移除IPBE的。--Techyan（留言） 2019年7月12日 (五) 02:16 (UTC)

如果要改為寬鬆方案，我強烈建議交由Jimmy-abot自動6個月不活躍除權（註：會在除權前一個月發討論頁通知，這目前已有執行）。--Xiplus#Talk 2019年7月13日 (六) 13:22 (UTC)

---

本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

长期不活跃除权的问题

刚刚重新筛了一下上面的讨论，发现还有一个问题没有解决，即对于长期不活跃的用户是否应该除权、具体怎么除权的问题。当前的做法是由A2093064-bot在用户六个月没有编辑活动后警告一次，如果之后一个月还没有编辑，那么就提报Wikipedia:申请解除权限来让管理员手动除权。如我前面所说，目前对于不活跃的带IPBE权限的用户，机器人对他们的处理方法跟处理有巡查权、回退权，但是也同样长时间不活跃的用户一样。对于IPBE这样广泛发放的权限，很明显让机器人先提报，然后再由管理员除权的做法比较麻烦，也如上面Xiplus所说，不活跃除权的工作可以交给jimmy-abot来操作。

所以现在还需要从这几个选项当中择一：

• 不除权。某用户在得到永久有效的IPBE后，可以无限期保留该权限，除非有滥用的情况出现。
• 直接除权。不需要经过管理员二次复核，直接由机器人对不活跃的用户除权。
• 维持现状。

另外从我个人的经验来看，我监视了一些我批IPBE的用户的讨论页。其中，我协助创建账号，批权限，一直到封禁都没有做出过一笔编辑的用户占了不小的一部分比重。但是与此对应的是，也有一部分只零星编辑维基百科的用户在半年没有活跃后，重新申请IPBE的情况发生。所以，上面三种方案中，不除权对管理员是最省事的，并且似乎也不会导致什么问题（IPBE不是什么很重要的权限，注册后从来不编辑的“僵尸账号”和被盗等都不是太大的问题）；如果决定在半年后除权，那么管理员需要给还需要IPBE的用户重新赋权，但是账号一定程度上会更安全。不知各位有何看法？

--Techyan（留言） 2019年8月5日 (一) 15:47 (UTC)

我希望还是半年除权。至于是手动还是自动，我的感觉是目前手动除权压力不大，可能不需要自动。我也想听一下 Xiplus 希望通过机器人自动除权的原因。--Tiger（留言） 2019年8月6日 (二) 02:43 (UTC)

cc@Xiplus--Techyan（留言） 2019年8月7日 (三) 16:21 (UTC)

有任何需要管理員覆核是否除權的需求嗎？如果沒有，那就應該全自動化。--Xiplus#Talk 2019年8月8日 (四) 00:25 (UTC)

• 既然 IPBE 都已經決定廣泛發放了，就沒有必要再擔心什麼帳號安全之類的問題。我認為可以直接使用不除權方案，直到本地拿回CU權限和/或中國解封維基百科。-- Vakrieger♀ 💢❤️🗯️ 2019年8月7日 (三) 14:13 (UTC)

距离上条发言也有一周了。虽然现在明显讨论还不够充分，但如果不行的话那就只能开投票了。--Techyan（留言） 2019年8月14日 (三) 13:53 (UTC)

• Vakrieger那句“中国解封维基百科”让我笑出了声。--🧧超级王💐同賀大典十三載，共書佳文千萬篇 2019年8月16日 (五) 03:16 (UTC)

建議修訂Wikipedia:特色圖片評選

完成，無異議，修訂通過，並於9月1日起提名FP的評選適用--Z7504非常建議必要時多關注評選（留言） 2019年8月20日 (二) 16:18 (UTC)

下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

---

為將{{yesFP}}和{{noFP}}兩個模板投入使用，並稍為收緊除名投票的保留要求，建議修訂Wikipedia:特色圖片評選#投票方法、Wikipedia:特色圖片評選#投票方法_2及Wikipedia:特色圖片評選#特色图片除名规则如下；提案將對另訂的實行日期開始的提名有效。산모사 ^DC17 2019年7月14日 (日) 12:04 (UTC)

（编辑冲突）對不起，非常抱歉，剛才上方編輯衝突後不知為何出現了差錯，我檢查修訂後才發現，對不起，非常抱歉-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月14日 (日) 12:11 (UTC)

Wikipedia:特色圖片評選#投票方法

−

==投票方法== 請你在提名或投票者前確保自己擁有[[Wikipedia:自動確認用戶|自動確認用戶資格]]，即註冊達7天及編輯達50次。 *如果支-{}-持該張圖片可以放進特色圖片中，請使用'''{{支持}}（{{Support}}）'''標籤，然後在後面加上理由。 *如果反對該張圖片可以放進特色圖片中，請使用'''{{反對}}（{{Oppose}}）'''標籤，然後在後面加上理由。'''反對理由必須有確實的論述，而非只是一句簡單的主觀評斷，比如「我不喜歡它的顏色」'''。 **如果你想要收回你的支-{}-持/反對的話，請將你的支-{}-持/反對'''劃除'''（在你的那段文字前後打上 <del>……</del>），而不是從頁面中移除。 *如果你僅僅是表達看法，請使用'''{{中立}}（{{Neutral}}）標籤'''，然後在後面加上你的觀點。 在提名與投票之後不要忘記加上日期與簽名（打上 ~~~~。）投票者應該留意投票過程的最新進展，並隨時間去更新他們的選票。 在投票之前，投票者應該先把圖片放到最大﹝即最高解像度﹞才評核圖片的質素。請留意此頁內所有圖片只是以縮圖的大小顯示。投票者應該按縮圖進入圖片說明頁面，然後再按圖觀看最高解像度之版本。此外，如果你認為你可以從編輯候選圖片中改善圖片的質素，請盡力去做，但留意請不要刪除或者改寫最原始的版本。反之，你應該用一個新的檔案名上載你已編輯的圖片﹝例如在本來的檔案名後加上「編輯」﹞，並放到原來的提名作品下面。所有編輯過的圖片應適當地順序表示﹝例如編輯1、編輯2，如此類推﹞，並仔細陳述圖片如何被編輯過。 '''切記要[[WP:CIVIL|文明處事]]，[[WP:BITE|不要傷害新手]]；發表意見時請針對圖片本身，而非[[WP:NPA|他人]]。''' ===评选结果=== 特色图片评选的周期是14天，候选图片评选14天后根据投票情况整理出投票结果。满足以下条件的图片可以当选特色图片： *候選圖片获得'''4张'''或以上的支-{zh-cn:援; zh-hk:持; zh-tw:持}-票；反对票与支-{zh-cn:援; zh-hk:持; zh-tw:持}-票1:1抵消。如下例所示： **圖片甲得到了7張支-{持}-票，2張反對票。当选特色图片。 **圖片乙得到了4張支-{持}-票，2張反對票。落选特色图片。 *提名者及投票者皆須擁有[[Wikipedia:自動確認用戶|自動確認用戶資格]]，即註冊達7天及編輯達50次，否則該提名或投票會被視為無效。 *參選特色圖片前，需上傳至[http://commons.wikimedia.org/wiki/Main_Page 維基共享資源]且在中文（zh）維基百科中至少1個條目被使用，而提名前須確保圖片沒有在維基共享資源中被提刪的疑慮，否則提名無效。

+

==投票方法== 請你在提名或投票者前確保自己擁有[[Wikipedia:自動確認用戶|自動確認用戶資格]]，即註冊達7天及編輯達50次。 *如果認同該張圖片可以放進特色圖片中，請使用'''{{yesFP}}'''標籤，然後在後面加上理由。 *如果不認同該張圖片可以放進特色圖片中，請使用'''{{noFP}}'''標籤，然後在後面加上理由。 **投「不符合特色圖片標準」票者須明確根據[[WP:特色圖片標準|特色圖片標準]]指出圖片如何不符合標準，亦不能添加主觀的意見，否則視為無效；如該票為提名人票，則該票以及該次評選本身也會被視為無效。 **如果你想要收回你的投票的話，請將你的投票'''劃除'''（在你的那段文字前後打上 <del>……</del>），而不是從頁面中移除。 *如果你僅僅是表達看法，請使用'''{{中立}}（{{Neutral}}）標籤'''，然後在後面加上你的觀點。 在提名與投票之後不要忘記加上日期與簽名（打上~~~~。）投票者應該留意投票過程的最新進展，並隨時間去更新他們的選票。 在投票之前，投票者應該先把圖片放到最大﹝即最高解像度﹞才評核圖片的質素。請留意此頁內所有圖片只是以縮圖的大小顯示。投票者應該按縮圖進入圖片說明頁面，然後再按圖觀看最高解像度之版本。此外，如果你認為你可以從編輯候選圖片中改善圖片的質素，請盡力去做，但留意請不要刪除或者改寫最原始的版本。反之，你應該用一個新的檔案名上載你已編輯的圖片﹝例如在本來的檔案名後加上「編輯」﹞，並放到原來的提名作品下面。所有編輯過的圖片應適當地順序表示﹝例如編輯1、編輯2，如此類推﹞，並仔細陳述圖片如何被編輯過。 '''切記要[[WP:CIVIL|文明處事]]，[[WP:BITE|不要傷害新手]]；發表意見時請針對圖片本身，而非[[WP:NPA|他人]]。''' ===评选结果=== 特色图片评选的周期是14天，候选图片评选14天后根据投票情况整理出投票结果。满足以下条件的图片可以当选特色图片： *候選圖片获得'''8张'''或以上的“符合特色圖片標準”票；“不符合特色圖片標準”票与“符合特色圖片標準”票1:1抵消。如下例所示： **圖片甲得到了10張“符合特色圖片標準”，2張“不符合特色圖片標準”票。当选特色图片。 **圖片乙得到了8張“符合特色圖片標準”，2張“不符合特色圖片標準”票。落选特色图片。 *提名者及投票者皆須擁有[[Wikipedia:自動確認用戶|自動確認用戶資格]]，即註冊達7天及編輯達50次，否則該提名或投票會被視為無效。 *參選特色圖片前，需上傳至[http://commons.wikimedia.org/wiki/Main_Page 維基共享資源]且在中文（zh）維基百科中至少1個條目被使用，而提名前須確保圖片沒有在維基共享資源中被提刪的疑慮，否則提名無效。 *一個評選／重審完結後，應設一道至少1个月的「冷靜期」，才可（再）提交評選／重審。

Wikipedia:特色圖片評選#投票方法_2及Wikipedia:特色圖片評選#特色图片除名规则

−

===投票方法=== 請使用'''{{除名}}（{{Delist}}）'''或者'''{{保留}}（{{Keep}}）'''標籤來表明你的投票意向。 ===特色图片除名规则=== 对于已现有的特色图片，维基人可以提起除名投票，除名条件如同特色圖片評選： *获得'''4张'''以上的除名票。 *保留票与除名票1:1抵消。 *提名者及投票者皆須擁有[[Wikipedia:自動確認用戶|自動確認用戶資格]]，即註冊達7天及編輯達50次，否則該提名或投票會被視為作廢。 *投票期限为14天。 *同一圖片不可以第一度重審未完結時，就進行第二度重審。 *一個重審／評選完結後，應設一道至少1个月的「冷靜期」，才可（再）提交重審。 *重審提名無須附上理由（但提名者自動視為除名，以防破壞），所有保留或除名的意見，包括提名者的意見，均於投票區以{{[[Template:保留|保留]]}}、{{[[Template:除名|除名]]}}、{{[[Template:中立|中立]]}}和{{[[Template:意見|意見]]}}，再附加意見來表達。但提名者必須表態，並只視之個人見解，不影響重審的「合法性」，而不附理據的投票，將視之無效。

+

===投票方法與除名规则=== 方法和規則皆與[[Wikipedia:特色圖片評選#投票方法|提名規則]]相同。 *一個評選／重審完結後，應設一道至少1个月的「冷靜期」，才可（再）提交評選／重審。 *重審提名無須附上理由（但提名者自動視為除名，以防破壞），所有保留或除名的意見，包括提名者的意見，均於投票區以{{[[Template:yesFP|yesFP]]}}、{{[[Template:noFP|noFP]]}}、{{[[Template:中立|中立]]}}和{{[[Template:意見|意見]]}}，再附加意見來表達。但提名者必須表態，並只視之個人見解，不影響重審的「合法性」，而不附理據的投票，將視之無效。

• 提案基本可以，不過細節部份（比如淨支持票問題）看要不要拉高比如至8這種水平，FP現在快200了，也遠遠超過FL了。也早該換成{{yesFP}}、{{noFP}}投票法代替了。不過在此提案通過前，所有使用的{{支持}}、{{反對}}將仍然有效--Z7504非常建議必要時多關注評選（留言） 2019年7月14日 (日) 12:34 (UTC)
  • User:Z7504我認為現階段暫時不要更動淨支持票，FP多未必是壞事。산모사 ^DC17 2019年7月14日 (日) 13:44 (UTC)
• 我觉得Yes/NoFP和支持反对没有区别，另外FP多一点没什么，反正之前总有恶意提请除名的事。--超级王（昔有地图开疆，今有易帜救国） 2019年7月17日 (三) 00:25 (UTC)
  • 某方面來說的確和支持反對票模板沒有區別，但除名的時候使用的則是「{{保留}}」/「{{除名}}」，而非「{{支持}}」/「{{反對}}」。如果通過後統一使用「{{yesFP}}」/「{{noFP}}」似乎和其他投票模板使用方法顯得一致，也不會搞混--Z7504非常建議必要時多關注評選（留言） 2019年7月17日 (三) 10:25 (UTC)
• 大家注意：以上修訂也同時收緊除名投票中保留特色圖片資格的條件，不再是少於四票除名，而是四票或以上保留。산모사 ^DC17_{FLC GAC} 2019年7月17日 (三) 11:05 (UTC)
  • (？)疑問：所以重審結果如果是「淨4個{{noFP}}（含）以上」是撤銷FP資格嗎?--Z7504非常建議必要時多關注評選（留言） 2019年7月17日 (三) 11:59 (UTC)
    • User:Z7504是。因為在新規則下，即使是重審，也只有「淨4票{{yesFP}}（含）以上」才可保留FP資格，少一票{{yesFP}}也不行，何況是「淨4票{{noFP}}（含）以上」？산모사 ^DC17_{FLC GAC} 2019年7月17日 (三) 13:31 (UTC)
      • 簡而言之，新FL結果規則是（正數為{{yesFP}}票，負數為{{noFP}}票）：淨票數≥4入選FP/保留FP資格；淨票數<4（甚至負數）則落選FP/撤銷FP資格。산모사 ^DC17_{FLC GAC} 2019年7月17日 (三) 13:31 (UTC)
      • 理解了（這樣要撤銷一個可能不適合在FP的圖片才不會覺得很困難XD）--Z7504非常建議必要時多關注評選（留言） 2019年7月17日 (三) 13:41 (UTC)
• 想請@Mys_721tx：發表意見，特別是有關冷靜期的部分。--Temp3600（留言） 2019年7月19日 (五) 18:55 (UTC)

  鉴于之前的WP:GAME，在收紧入选条件前，反对任何对重审的限制。-Mys_721tx（留言） 2019年7月19日 (五) 19:18 (UTC)

  此提案是收緊重審維持條件，並不對提出重審本身造成限制。（而且之前好像也收緊了入選條件了？）산모사 ^DC17_{FLC GAC} 2019年7月21日 (日) 13:58 (UTC)

  然後我發現之前收緊投票理由以變相收緊入選條件的提案通過了卻沒有寫進去……索性與此提案一同加入好了。산모사 ^DC17_{FLC GAC} 2019年7月21日 (日) 14:06 (UTC)

  我相信我與@Mys_721tx：都反對冷靜期的設立。--Temp3600（留言） 2019年7月24日 (三) 15:39 (UTC)

  理論上，冷靜期早已經設立了，所以這反對並沒有甚麽意思，那部分只是事實性修訂而已。산모사 ^DC17_{加泰隆尼亞圖書館GAN} 2019年7月25日 (四) 11:43 (UTC)

• 如果稍微有关注commons上的fp讨论，就知道中文wiki的门槛低到令人发指。希望能有所改善。☺️~ viztor ✪ 2019年7月19日 (五) 21:51 (UTC)
  • (？)疑問@Viztor：那commons的評選標準和制度又是如何呢?--Z7504非常建議必要時多關注評選（留言） 2019年7月21日 (日) 14:10 (UTC)
    • commons也无非是投票，只是那里专业摄影师很多。大多是他们投票所以质量比较好。~ viztor ✪ 2019年7月22日 (一) 14:37 (UTC)
    • 据觀察，commons要求當地FP入選需要≥7票淨支持，候選期為時9日。Despite本地FP候選期為時7日，把票數要求提高至≥6票淨符合標准可以考慮。산모사 ^DC17_{加泰隆尼亞圖書館GAN} 2019年7月25日 (四) 11:43 (UTC)
• 至於英維，他們FP入選需要5張支持票，且支持票佔所有投票至少三分之二，候選期為10日。--A1Cafel（留言） 2019年7月26日 (五) 13:57 (UTC)
  • (＋)同意本地FP評選門檻頗低，但又未見氾濫情況，六票淨支持是個可行方案。不過考慮本地FP評選較少人關注，建議候選期維持14天。--A1Cafel（留言） 2019年7月26日 (五) 14:15 (UTC)
    • 我以為這裏的候選期是七天……那我改為提案提升要求至≥8票淨符合標准。산모사 ^DC17_FLC 2019年7月31日 (三) 00:51 (UTC)

---

以上提案已經修改，我打算3日後公示。산모사 ^DC17_{GAC FLC} 2019年8月4日 (日) 08:11 (UTC)

• 现公示七日。산모사 ^DC17_{GAC FLC} 2019年8月7日 (三) 02:26 (UTC)
• 基本沒意見，只是通過後相對的提名模板參數要改一下就是了--Z7504非常建議必要時多關注評選（留言） 2019年8月7日 (三) 04:56 (UTC)
• 所以现在的FP评选是完全和FL拉齐了吗？--超级王（昔有地图开疆，今有易帜救国） 2019年8月8日 (四) 00:50 (UTC)
  • 確實可以這樣理解。都是F字頭，總也不能和另外兩個F差太遠。산모사 ^DC17_{GAC FLC} 2019年8月8日 (四) 07:44 (UTC)
• 我先暫緩公示，我決定修改提案。산모사 ^DC17_{GAN FLN} 2019年8月10日 (六) 08:31 (UTC)
  • 重新公示七日，並定通過後於9月1日及以後的提名方適用。산모사 ^DC17_{GAN FLN1 FLN2} 2019年8月12日 (一) 15:31 (UTC)

---

本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

收集社群對关注度流程的意見

点击这里返回原讨论

---

基于原关注度流程开展，可参考前述讨论。议题和提案区请不要冗长讨论，尽量以一次纯文字的发言说明自己的逻辑，不要使用任何模板，列表，加大字体，多段落或者复制任何发言，可以对是否部分加粗。任何其他类型的回应请在讨论区进行。不符合规则可能被回退/移动。谢谢配合。下述为目前观察到的议点。~ viztor ✪ 2019年7月16日 (二) 06:56 (UTC)

---

1. 目前条目存废讨论中涉关注度条目是否有积压情况？

• 是 ~ viztor ✪ 2019年7月16日 (二) 06:55 (UTC)
• 有，但不嚴重。--【和平至上】💬📝 2019年7月16日 (二) 13:35 (UTC)
• 有，在我个人观察来看，积压的存废讨论中时常很大一部分都是关注度相关的--百無一用是書生 (☎) 2019年7月17日 (三) 07:41 (UTC)
• (▲)同上--Cohaf(talk) 2019年7月17日 (三) 12:57 (UTC)
• 有。--Temp3600（留言） 2019年7月19日 (五) 18:50 (UTC)
• 非常嚴重，熱血提刪，批量提刪的情況越來越嚴重，而且有不少都是誤報。--蟲蟲飛♡♡→♡℃※留言 2019年7月20日 (六) 03:56 (UTC)
• 除了兩極化（vd/vk），都積很久-- Sunny00217 - 2019年7月21日 (日) 14:28 (UTC)
• 有是有，但我不認為存废讨论积压本身是一個問題（即使不涉关注度也一樣）。산모사 ^DC17_{加泰隆尼亞圖書館GAN} 2019年7月25日 (四) 11:57 (UTC)
• 一部份有，但不算緊急。--A1Cafel（留言） 2019年7月26日 (五) 14:10 (UTC)
• 有。—— Eric Liu_{（留言．留名．學生會）} 2019年7月26日 (五) 15:17 (UTC)
• 有，而且相當嚴重。—Gompertz在原野上遨遊_{8·5全民三罷 連儂牆 GAC DYKC} 2019年8月6日 (二) 06:46 (UTC)
• 有。宜改善流程。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月10日 (六) 17:52 (UTC)

2. 关注度流程是否有改善空间

• 是 ~ viztor ✪ 2019年7月16日 (二) 06:55 (UTC)
• 有很大的改善空間，因為大部分條目在這30天內都沒有加入來源。--【和平至上】💬📝 2019年7月16日 (二) 13:35 (UTC)
• 可以有--百無一用是書生 (☎) 2019年7月17日 (三) 07:41 (UTC)
• (▲▲▲)同上上上--Cohaf(talk) 2019年7月17日 (三) 12:57 (UTC)
• 有，現在提刪門檻太低，註刪七天已可提刪，建議提高提刪用戶的門檻，因為只註冊七天的用戶，不熟悉方針，不建議太早進行提刪。--蟲蟲飛♡♡→♡℃※留言 2019年7月20日 (六) 04:00 (UTC)
• (▲)同上-- Sunny00217 - 2019年7月21日 (日) 14:28 (UTC)
• 毋庸置疑有，但一定不是提刪門檻太低。산모사 ^DC17_{加泰隆尼亞圖書館GAN} 2019年7月25日 (四) 11:57 (UTC)
• 同書生君及Sanmosa。--A1Cafel（留言） 2019年7月26日 (五) 14:10 (UTC)
• 有。—— Eric Liu_{（留言．留名．學生會）} 2019年7月26日 (五) 15:17 (UTC)
• 是有的，但需要一個社群普遍滿意的方式。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月10日 (六) 17:52 (UTC)

3. 挂关注度模板是否应当批量提报删除？

• 不应当，所有关注度提删都应当有理据，否则无法讨论。若条目中无任何来源/仅UGC可考虑快速删除，后或可由管理员转交。~ viztor ✪ 2019年7月16日 (二) 06:55 (UTC)
• 不應該全部提刪，應先檢視在流程後條目內有沒有明顯無爭議、可以用作佐證關注度的來源。如有，則不應提刪。剩下的就可以全部提刪。--【和平至上】💬📝 2019年7月16日 (二) 13:35 (UTC)
• 把明显有关注度的条目剔除后，可以批量提删（也就是现在常用的方式）--百無一用是書生 (☎) 2019年7月17日 (三) 07:41 (UTC)
• 可--Cohaf(talk) 2019年7月17日 (三) 12:57 (UTC)
• 如果一个批次（例如同一天提报的）经过期限复核后仍有问题，应按照规定提删讨论处理，而且可以批量一并提交。——路过围观的Sakamotosan | 避免做作，免敬 2019年7月18日 (四) 00:34 (UTC)
• 同意User:Viztor的看法，建議批量提刪也在每個提刪也註明理據，儘量避免自動化提刪，我們也應審慎處理每個提刪，不要嚇怕新手。提刪前最好先幫忙改善條目，不要急於提刪。--蟲蟲飛♡♡→♡℃※留言 2019年7月19日 (五) 05:24 (UTC)
• 提刪者自行把關。經常提出不恰當提刪的編輯可被禁止參頁面。--Temp3600（留言） 2019年7月19日 (五) 18:58 (UTC)
• 批量提删当然可以，但是对每一个提删前都要做好工作，例如有一些条目其实主题有不少符合GNG来源的，但是条目已有来源确实看起来糟糕，却也在批量提删时被考虑入内，应当尽量避免。以及是否有删除之外的其它选择（总的来说类似en:WP:BEFORE）--及时雨 ^留言 2019年7月20日 (六) 15:55 (UTC)
• 反對，量太多-- Sunny00217 - 2019年7月21日 (日) 14:28 (UTC)
• 這是現行的慣常做法，集中所有關注度AFD討論，方便其他用戶去classify。我的意見同書生（而我先前在進行AFD提刪時也有做相關功夫）。산모사 ^DC17_{加泰隆尼亞圖書館GAN} 2019年7月25日 (四) 11:57 (UTC)
• 不建議。—— Eric Liu_{（留言．留名．學生會）} 2019年7月26日 (五) 15:17 (UTC)
• (－)反对，有機會助長不熟悉事務的編輯不負責任的操作。——約克客（留言） 2019年7月27日 (六) 12:30 (UTC)
• 我覺得可以，但需要篩選。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月10日 (六) 17:52 (UTC)

4. 新条目在提起讨论（AfD）前是否应当有改善保护期？该有多长？

• 应当不鼓励急速提起讨论，假定作者在条目创建的24小时内仍然是积极工作状态，此时除非明显有害内容，否则应当避免吓唬到积极工作的编者，但应当由巡查员自律，难以做硬性规定，不符合常识的操作应当被提醒，但不应当被撤销。~ viztor ✪ 2019年7月16日 (二) 06:55 (UTC)
• (－)反对：難以硬性規定，應由巡查員視情況而定。（例如仍然在大幅度更新，而內容又沒有大問題的話，可以稍候再巡查）--【和平至上】💬📝 2019年7月16日 (二) 13:35 (UTC)
• 我不认为这应当由巡查員负责。也不应该有硬性规定，但是建议性质的要求是可以的。毕竟不可能随机看到一个条目有问题，要提删的话还得看一下版本历史是否刚建立才可以--百無一用是書生 (☎) 2019年7月17日 (三) 07:41 (UTC)
• (－)反对--Cohaf(talk) 2019年7月17日 (三) 12:57 (UTC)
• 如果指提删讨论时，与现有提删讨论时限一致；如果指提报关注度期间，应该给予足够而合适的时间。从管理上的便捷，应该避免个例化，但不硬性通例时间而允许有“成功快速逃脱”。——路过围观的Sakamotosan | 避免做作，免敬 2019年7月18日 (四) 00:37 (UTC)
• 可建议，但不强制 比如A1、A2，不应很快就提，除非明显有害的G3/G12 有时G11可以马上提，其它的在速删、提删、挂板前都应给予一定时间，以免使人受到惊吓 --及时雨 ^留言 2019年7月18日 (四) 01:55 (UTC)
• (－)反对，有些東西要到存廢才有人會看，沒提有些人不會刻意理-- Sunny00217 - 2019年7月21日 (日) 14:28 (UTC)
• 不能硬性規定，技術上做不到。산모사 ^DC17_{加泰隆尼亞圖書館GAN} 2019年7月25日 (四) 11:57 (UTC)
• (－)反对，大部份條目不見棺材不流眼淚。--A1Cafel（留言） 2019年7月26日 (五) 14:10 (UTC)
• (＋)支持，建議可設立彈性保護期7到15日，並設計建立註明模板，以吸引編輯審視有關條目，可提高促進新條目改善機率。——約克客（留言） 2019年7月27日 (六) 12:30 (UTC)
• 覺得7天到28天之間可以。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月10日 (六) 17:52 (UTC)

5.除了新条目保护期外，关注度问题是否应当有额外提起讨论(AfD)避免期？

• 不，关注度本身不特殊，赋予额外保护区不符合逻辑。应当由社群依个案判断是否可改善。但可视是否需要线下来源或者难以搜寻来源的情况，给予7天左右改善期，可延长一次7天，此时存废投票应当暂停，但仍可以讨论，恢复时，可应当要求此前讨论者重新投票。~ viztor ✪ 2019年7月16日 (二) 06:55 (UTC)
• 不應該區別對待。因為關注度問題的唯一區別在於找來源可能需要時間（而不是為了新手），可以給予14天的時間便足矣。--【和平至上】💬📝 2019年7月16日 (二) 13:35 (UTC)
• 至少之前的讨论看来，14天足够长，已经能满足绝大多数情况。但是如果不设额外期限，个人认为也可以--百無一用是書生 (☎) 2019年7月17日 (三) 07:41 (UTC)
• 14天--Cohaf(talk) 2019年7月17日 (三) 12:57 (UTC)
• 從Tiger提供的數據顯示，有八十多個用戶仍在十四天後努力改善條目，30天的流程是合理，也可顧及新手的處境及需要，符合程序公義。--蟲蟲飛♡♡→♡℃※留言 2019年7月20日 (六) 04:07 (UTC)
• 不要再加時間了，一個月很夠了-- Sunny00217 - 2019年7月21日 (日) 14:28 (UTC)
• 應該減到14日，實例是絕大部分條目可以在14日内改善。산모사 ^DC17_{加泰隆尼亞圖書館GAN} 2019年7月25日 (四) 11:57 (UTC)
• (＋)同意十四天的提案。--A1Cafel（留言） 2019年7月26日 (五) 14:10 (UTC)
• 不應。—— Eric Liu_{（留言．留名．學生會）} 2019年7月26日 (五) 15:17 (UTC)
• (！)意見認為首先需要有更醒目的模板索引，便利編輯注意到正處於被掛上改善期限的具體條目，而對於若有一定難度或缺乏專業編輯等的，可個別彈性增加額外時間。基本限期維持30日。——約克客（留言） 2019年7月27日 (六) 12:30 (UTC)
• 跟4.加總應落在7天到28天之間可以。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月10日 (六) 17:52 (UTC)

6. 条目讨论（AfD）的期限应当是多长？

• 通常应当为7天，但由于部分无人处理，大部分超过7天。因此建议通常讨论7天，关注度14天后若无人讨论，可直接关闭，但不视作为“保留”，即仍然可以被提请讨论。~ viztor ✪ 2019年7月16日 (二) 06:55 (UTC)
• 7天≤<X<14天--Cohaf(talk) 2019年7月17日 (三) 12:57 (UTC)
• 如果指提报关注度期间，还是30天，足够长，而且本身现有规则就是有“成功快速逃脱”；如果指提删讨论时，这只是以“关注度存疑”的理由提删讨论，与其他提删讨论没明显差异。——路过围观的Sakamotosan | 避免做作，免敬 2019年7月18日 (四) 00:41 (UTC)
• 7天。但如果有人願意認領改善，可適量延長。--Temp3600（留言） 2019年7月19日 (五) 19:00 (UTC)
• 30天改善期，然後7天afd討論，但7天刪去後的條目甚少，一方面反映用戶提刪前未經審慎考慮，另一方面也反映關注度是一個複雜問題，多爭議，大家應審慎提刪。--蟲蟲飛♡♡→♡℃※留言 2019年7月20日 (六) 04:11 (UTC)
• 14天+7天，有編者明確表示會在近期（30天內）尋找合適來源的條目或許可以做出相應的延長。--【和平至上】💬📝 2019年7月23日 (二) 08:45 (UTC)
• 撇除現行的30日關注度，至少7日（即現行AFD情況）。산모사 ^DC17_{加泰隆尼亞圖書館GAN} 2019年7月25日 (四) 11:57 (UTC)
• 七天，三十天後仍無共識可以「無共識」結案，如完全無討論則可在十四天後以「無共識」結案。--A1Cafel（留言） 2019年7月26日 (五) 14:10 (UTC)
• 14日。—— Eric Liu_{（留言．留名．學生會）} 2019年7月26日 (五) 15:17 (UTC)
• 14日到30日。——約克客（留言） 2019年7月27日 (六) 12:30 (UTC)
  • @Ericliu1912、Longway22：你們這個時間是包括關注度流程（即提刪前的緩衝期）嗎？--【和平至上】💬📝 2019年8月2日 (五) 13:29 (UTC)
    • 計頁面存廢討論總時間。—— Eric Liu_{（留言．留名．學生會）} 2019年8月2日 (五) 13:33 (UTC)
    • (▲)同上——約克客（留言） 2019年8月3日 (六) 00:56 (UTC)
    • 即是在提交Afd之後的時間？那麼你們對於關注度緩衝期（掛關注度模板至提刪）的意見是？（多長？）--【和平至上】💬📝 2019年8月6日 (二) 06:55 (UTC)
      • 14日。—— Eric Liu_{（留言．留名．學生會）} 2019年8月7日 (三) 00:02 (UTC)
      • 30日。——約克客（留言） 2019年8月9日 (五) 01:54 (UTC)
• 建議4.跟5.加總應落在7天到28天之間。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月10日 (六) 17:52 (UTC)

7. 关注度是否应增加提删处理时间？

• 或可, 由于关注度积压，绝大部分疑难条目已经默认保留。因此无人讨论的情况下，或可按无共识结案，此时允许再次提删。~ viztor ✪ 2019年7月16日 (二) 06:55 (UTC)
• 不應，這樣不能解決任何問題，只是把「積壓」變成「處理中」，實際上沒有區別（甚至可能導致需要的時間進一步延長。至於無人討論、而條目裡又沒有需要的來源的情況下，應該視作沒有反對意見而刪除結案。--【和平至上】💬📝 2019年7月16日 (二) 13:35 (UTC)
• 除非一些特殊的情况，不应该。例如暂时没时间找线下来源的时候，可以说明一下情况，以及大概什么时间完成。这种时候临时积压在那里就可以了（或者暂时移动到草稿空间？）--百無一用是書生 (☎) 2019年7月17日 (三) 07:41 (UTC)
• 不應--Cohaf(talk) 2019年7月17日 (三) 12:57 (UTC)
• 不应该，这已经说明条目的关注度已经存在明显问题而且（在可见的时间内）无法改善，按照规则而言就不适宜再保留，除非以后再改善。另，“关注度存疑”的提删讨论和其他提删讨论没明显差异，不应该混为一谈。——路过围观的Sakamotosan | 避免做作，免敬 2019年7月18日 (四) 00:43 (UTC)
• 不應該。沒有人來救，再長也沒用。--Temp3600（留言） 2019年7月19日 (五) 19:02 (UTC)
• 应该。关注度和其他讨论的差异在于，大部分删除标准都是证明条件，但关注度是证伪条件。关注度的提删需要证伪“存在来源”（因为关注度的标准就是“存在一个来源，这个来源如何如何”），没有一个显著的长时间等候期，连证伪的希望都没有。这是关注度方针目前的问题，如果不解决这个问题而取消掉队列时间，是两错不等于一正。Bluedeck 祝福香港 2019年7月20日 (六) 00:52 (UTC)
• 30天關注度是一個合理時間，事實上提刪到afd後，七天後刪去的甚少，有不少討論超過五週，明顯應該「無共識保留」，見方針WP:CLOSEAFD，但卻沒有人處理。--蟲蟲飛♡♡→♡℃※留言 2019年7月20日 (六) 04:15 (UTC)
• (－)反对，同上面不應者-- Sunny00217 - 2019年7月21日 (日) 14:30 (UTC)
• 除非分離處理，否則不應該這樣做，這只會徒添混亂。산모사 ^DC17_{加泰隆尼亞圖書館GAN} 2019年7月25日 (四) 11:57 (UTC)
• (－)反对，(▲)同上。--A1Cafel（留言） 2019年7月26日 (五) 14:10 (UTC)
• 不。—— Eric Liu_{（留言．留名．學生會）} 2019年7月26日 (五) 15:17 (UTC)
• 此處斟酌應聯同第5，(！)意見認為要維持現行時間限制，還需增添更醒目的被掛模板的條目索引目錄等配合，此舉措可便利更多編輯注意而提高改善機率，從而減低關注度擠壓負擔。——約克客（留言） 2019年7月27日 (六) 12:30 (UTC)
• 建議4.跟5.跟7.加總應落在7天到28天之間。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月10日 (六) 17:52 (UTC)

总结陈述

可以至多一次，一段话陈述自己现在的看法。

• （我的想法還是一樣，而又沒有反駁，所以我複製一次我的論點）

(＋)支持修改：沒有關注度的條目因難以確保準確性、中立性，會對維基百科造成危害，因此應在合理的時間內進行刪除；

在設立關注度指引之初，加入30天的緩衝期的目的是希望能給予編者合適的時間察覺問題、尋找來源。（而且當初根本就沒有討論過多長是合適的，只是一開始有人提出30天然後各人附議）然而，根據實際情況，大部分的條目都不會用到14-30天這段時間來增補來源（也就是改善這條目），因此可見當初設立30天的目的明顯不能達到。

在其失去意義或者意義甚微的情況下，再加上上面提及沒有關注度的條目造成的危害，理應將先行的30天緩衝期修正至更符合現實絕大部分情況的14天，以達至更佳的平衡點，在確保編者和新手也有足夠合適的時間做出改善的情況下，減低對維基百科的危害。--【和平至上】💬📝 2019年7月16日 (二) 13:35 (UTC)

• 我懒得长篇大论。简单。问题是关注度页面积压。以及没有任何人与主编好好沟通，通常挂了模版就跑。以及去有些原生广告会被延长寿命。(＆)建議多与主编沟通，挂模版时候通知主编，14天有人去检查主编进度，如果主编没有信心可帮忙之就帮忙，不可帮忙之可以建议草稿化，或者也可以建议主编G10。请考虑新手不能被咬，挂模版，一个或者多个非常可怕，所以请考虑教育新手使用WP:创建条目专题。原生广告如果14天后没人理会，就是那些提删广告但被暂时保留的条目，去草稿，那儿noindex--Cohaf(talk) 2019年7月17日 (三) 12:57 (UTC)
• 一、任何存废讨论积压本身並不是一個問題（包括但不限於關注度）。二、30日是浪費社群16日的時間和精力，14日才符合實況。산모사 ^DC17_{加泰隆尼亞圖書館GAN} 2019年7月25日 (四) 11:57 (UTC)

讨论区

• 不ping了，太多人。~ viztor ✪ 2019年7月16日 (二) 06:55 (UTC)

• 根據J.Wong的意見是先收集社群的意見，而不是再重新提案，更不是重新加七萬字爭論。--蟲蟲飛♡♡→♡℃※留言 2019年7月16日 (二) 07:17 (UTC)

收集意见就是这种形式。如果按照题中规则，且讨论区克制。显然不会7万字。~ viztor ✪ 2019年7月16日 (二) 07:24 (UTC)

• 爭論多天，我覺得很累，看看誰還有精力，先在上面發表意見，我先休息一下。 囧rz...--蟲蟲飛♡♡→♡℃※留言 2019年7月16日 (二) 07:29 (UTC)

@蟲蟲飛：可以給與意見了嗎？好像今天您有空--Cohaf(talk) 2019年7月17日 (三) 13:02 (UTC)

• 討論多天，很累，想休息一下，你們先討論吧﹗--蟲蟲飛♡♡→♡℃※留言 2019年7月17日 (三) 13:12 (UTC)
• 已發言-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月18日 (日) 05:12 (UTC)

• 我希望在上面看到的是自己的意見，而不是又複製別人的意見。--【和平至上】💬📝 2019年7月16日 (二) 13:43 (UTC)
• (＆)建議將這討論移到頁面最底，因為這也算新討論，而且這樣更加容易被更多的編者看到。--【和平至上】💬📝 2019年7月18日 (四) 00:51 (UTC)
  • 已移動。—— Eric Liu_{（留言．留名．學生會）} 2019年7月18日 (四) 05:39 (UTC)

@蟲蟲飛： 评论可以移动到这里来吗，谢谢。~ viztor ✪ 2019年7月18日 (四) 07:50 (UTC)

完成—以上留言未簽名。

• 和平君已明確建議不要再複製粘貼留言，請Cohaf不要再複製粘貼留言，你看看你上面的留言是複製粘貼自之前的討論，而且一字一句完全一樣。—以上留言未簽名。

(※)注意：從數據顯示有大量編輯仍在14後改善條目，匆匆刪去條目只會嚇怕新手，最終被批評為「未給予足夠時間改善就刪去條目」，這是屬於制度上的漏洞，也不符合程序公義。上面七萬字已經討論了14天和30天等不同日期的議題，J.Wong也建議縮短流程不能解決問題，建議探討其他的解決方案，否則只會令討論再僵持七萬字也沒有結果。--蟲蟲飛♡♡→♡℃※留言 2019年7月18日 (四) 05:11 (UTC)

• 我們現在討論的就是14日是否合適的時間，所以這個程序正義無關。另我再次邀請你在上方發表你的意見。--【和平至上】💬📝 2019年7月19日 (五) 04:18 (UTC)
• 实践中观察到有人直接批量提删所有，认为需要提醒这些用户在提报前进行检查。~ viztor ✪ 2019年7月19日 (五) 05:26 (UTC)
  • 同意，有一些用戶會在提刪時排除掉已有關注度來源的條目，這才是合適做法。--【和平至上】💬📝 2019年7月23日 (二) 08:43 (UTC)

• 謝謝User:和平至上邀請﹗完成我意見很簡單，就是審慎提刪，不要嚇怕新手，詳見上面論述。--蟲蟲飛♡♡→♡℃※留言 2019年7月19日 (五) 05:30 (UTC)

@和平至上：之前太忙，現在才再在上面補充更多的意見。--蟲蟲飛♡♡→♡℃※留言 2019年7月20日 (六) 04:18 (UTC)

解決未巡查頁面消失的問題

現在還沒有巡查頁面問題嚴重，有些條目30天後還沒有巡查。沒巡查條目存在廣告、侵權、不符收納問題。30天後就不能知道那些沒有巡查。參考User:Xiplus/沙盒6。所以提議列出未巡查頁面，計算創建至今時間t，t>=29天發送api，頁頂標記Template:未巡查，已標過的不重複，每天重複上述動作。這是確定性演算法。希望有共識通過。--Cohaf(talk) 2019年7月20日 (六) 09:03 (UTC)

• • (～)補充简短来说，就是用机器人来解决问题。--Cohaf(talk) 2019年7月20日 (六) 09:41 (UTC)
• 你列的是機器人演算大略步驟

若要用機器人的參考演算法

• • 每天執行的task
    • 使用api獲得所有未巡查頁面 放入陣列 未巡查頁面陣列
    • foreach 未巡查頁面iterator in 未巡查頁面陣列 do
      • 計算t = 未巡查頁面iterator創建至今所經過的時間
      • if t >= 29 天 則
        • 發送api獲得 未巡查頁面iterator 的內容
        • if [未巡查頁面iterator 的內容] 中不含有模板{{未巡查}} (編輯 討論 說明  信息 鏈入 歷史)（含各重定向/別名的檢查） 則
          • 發送編輯api 內容為在未巡查頁面iterator頁頂加入{{未巡查}}
        • end if
      • end if
    • end for
  • end task

• (！)意見不過這裡要討論的主題應該是「應不應該將30天未巡查的條目，透過掛上{{未巡查}} (編輯 討論 說明  信息 鏈入 歷史)來防止漏掉巡查」的方針議案。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月20日 (六) 09:23 (UTC)
• (＋)支持「應該將30天未巡查的條目，透過掛上{{未巡查}} (編輯 討論 說明  信息 鏈入 歷史)來防止漏掉巡查」理據：

  這樣才不會有不合格的條目被因30天無人標記巡查而留下且未作任何處理-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月20日 (六) 09:31 (UTC)

• (＋)支持--Techyan（留言） 2019年7月20日 (六) 10:15 (UTC)
• (＋)支持--Jpcomic-wsu_留言 2019年7月20日 (六) 10:54 (UTC)
• (＋)支持。—— Eric Liu_{（留言．留名．學生會）} 2019年7月20日 (六) 11:11 (UTC)
• (＋)支持，另(＆)建議可以通过WP:AF阻止新用户/条目创建者移除Template:未巡查模版。--AlexLeeCN（留言） 2019年7月20日 (六) 11:18 (UTC)
• (＋)支持连同下方条文修改，另(？)疑問：重定向如何处理？我们似乎有太多重定向都是过了30天都没有巡查。重定向再手动巡查是否有必要？还是放过？并(＆)建議Special:最新页面顶部文字修改--及时雨 ^留言 2019年7月20日 (六) 14:40 (UTC)
• (？)疑問：是否存在过滤器防止非巡查员摘走未巡查模版？是否应该创建该过滤器？？Bluedeck 祝福香港 2019年7月21日 (日) 04:27 (UTC)
  • (？)疑問@Bluedeck：閣下不是可以自己設嗎？-- Sunny00217 - 2019年7月21日 (日) 14:34 (UTC)
    • 可以，但是我还有是否应该设立这一问题呢。Bluedeck 祝福香港 2019年7月21日 (日) 16:35 (UTC)
      • @Bluedeck：可以有过滤器，谢谢制作。--Cohaf(talk) 2019年7月22日 (一) 07:54 (UTC)
• popup一下诸上的权限，居然不少是巡查员或者管理员（这些人本来就是可以去清这些的）。有这个闲情去投票，还不如快去干活，看一下挂个标识，再多指导下怎样改善或者自己动手，有这么难吗？简直滑天下之大稽。所以我(－)反对，最近这么喜欢为解决“问题”而制造“问题”？——路过围观的Sakamotosan | 避免做作，免敬 2019年7月22日 (一) 07:25 (UTC)
• (＋)支持--KMB-ATENU139（Talk） 2019年7月22日 (一) 10:47 (UTC)
• (－)反对:搞到那麼複雜，提案人cohaf一個月才巡查十幾次，為甚麼自己不動手去巡查一下呢？30天不去巡查，要去掛「未巡查」模板，掛了模板，然後誰去處理那些模板呢？--蟲蟲飛♡♡→♡℃※留言 2019年7月28日 (日) 06:56 (UTC)
  • @蟲蟲飛：虽然我也不赞成这部分提案（理由在下列过），提案合理性与Cohaf君这个月巡查了多少无关，巡查的少也不损害如果提案合理也不损害其合理性，巡查的多也不增加其合理性，况且Cohaf君这段时间大量时间贡献于WP:DC17，而我只是在过去两周把大量本应参与主持的时间分给了积压严重的巡查而已。因此，诉诸于Cohaf君过去一个月的巡查量，实感不妥。--Kirk★ 0讨论│图书馆0 2019年7月28日 (日) 15:40 (UTC)

@KirkLU：同意您的觀點，我上面的意思可能說得不夠清楚，我的意思不是批評他巡查量，而是要說明不去巡查，掛一個「未巡查」的模板，問題還未解決，而且令制度更加複雜；理由和您下面的論述一樣。--蟲蟲飛♡♡→♡℃※留言 2019年7月28日 (日) 15:50 (UTC)

• 诶，感谢回应和澄清，其实跟我后面说的一样，制度问题挺重要的，现在的积压固然是我们巡查员动手少了，但是制度优化也蛮关键。所以也是非常在意这个系列提案。--Kirk★ 0讨论│图书馆0 2019年7月28日 (日) 17:35 (UTC)

• 大家理性討論，勿訴諸人身。--Cohaf(talk) 2019年7月28日 (日) 17:40 (UTC)

@Cohaf：上面批評您巡查量的話是不適當的，傷了您的心，因此謹此致歉，並撤回那個言論。蟲蟲飛♡♡→♡℃※留言 2019年8月11日 (日) 14:13 (UTC)

• (！)意見，看到{{不定积分}} (編輯 討論 說明  信息 鏈入 歷史)（Wikipedia:頁面存廢討論/記錄/2019/08/10#Template:不定积分）被從2014年放置至今（至少4年以上了）無人處理後，看到無巡查紀錄，我就更認為有把30天無巡查的條目做接標記的必要，否則又會有奇怪的頁面被漏掉巡查。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年8月10日 (六) 21:37 (UTC)
• (＋)支持--Bagakuco（留言） 2019年8月11日 (日) 14:39 (UTC)
• (＋)支持{{未巡查}}及连同下方条文修改，並對cwek的言論深表遺憾。很多巡查员看到新條目都對於巡查時應該挂那些模板很頭疼（有時候就是很臨界那一種），按那個button不應該那麽輕率。산모사 ^DC17_{FLN1 FLN2} 2019年8月18日 (日) 04:32 (UTC)

條文修訂建議

對於Wikipedia:新頁面巡查修訂如下：

現行條文 在巡查日志中记录了所有的巡查，包括用户名，条目名称以及巡查的版本。日志可以按照用户名或条目标题排序。 由管理员、巡查者和机器人创建的页面会被自动标记为已巡查。 其他用户不能巡查自己创建的页面。 在Special:NewPages中可以选择“隐藏巡视过的修改”，这样你就可以忽略掉那些已经被检查过的页面。 未巡查的页面在720小时（30天）后将不能被巡查。 除了主命名空间（条目），其他命名空间（尤其是讨论页，用户页，用户讨论页与分类）也需要巡查，在Special:NewPages里面可以选择显示不同的命名空间的新页面。巡查员亦可以使用不隐藏任何新页面的设定来没有遗漏地巡查包括重定向在内的全部新页面。 重定向页面也需要适时巡查，以确保没有明显的破坏。

提議條文 在巡查日志中记录了所有的巡查，包括用户名，条目名称以及巡查的版本。日志可以按照用户名或条目标题排序。 由管理员、巡查者和机器人创建的页面会被自动标记为已巡查。 其他用户不能巡查自己创建的页面。 在Special:NewPages中可以选择“隐藏巡视过的修改”，这样你就可以忽略掉那些已经被检查过的页面。 未巡查的页面在720小时（30天）后将不能被巡查。 未巡查的頁面在720小時（30天）後巡查員將無法使用巡查紐標示為已巡查 除了主命名空间（条目），其他命名空间（尤其是讨论页，用户页，用户讨论页与分类）也需要巡查，在Special:NewPages里面可以选择显示不同的命名空间的新页面。巡查员亦可以使用不隐藏任何新页面的设定来没有遗漏地巡查包括重定向在内的全部新页面。 重定向页面也需要适时巡查，以确保没有明显的破坏。

以上-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月20日 (六) 11:22 (UTC)

(＆)建議这里是否应当是“拥有巡查 (patrol) 权限的使用者”或是类似语句而非“编者”？--Hamish歡迎來訪 2019年7月20日 (六) 17:15 (UTC)

“提醒其他编者协助巡查”的表述我觉得是可以的（任何人都可以“协助”巡查）。但是谁可以摘去模板应该明确：是否允许无巡查权用户摘去模板？如果是不允许则应完善表述并考虑设置阻止过滤器。如果允许则可考虑分别设置标记（无巡查权且非创建者/自动确认）、阻止（非创建者/自动确认）过滤器--及时雨 ^留言 2019年7月21日 (日) 02:22 (UTC)

想法同及时雨。只是可能我那句话过于限制了操作者，个人认为是模板是否可以借鉴unblock的处理方式，由拥有权限的人士复检。--Hamish歡迎來訪 2019年7月22日 (一) 04:51 (UTC)

此类模板在讨论页更适宜，或考虑分类而非模板。巡查与否与读者无关。~ viztor ✪ 2019年7月20日 (六) 22:31 (UTC)

(：)回應：模板{{未巡查}} (編輯 討論 說明  信息 鏈入 歷史)自帶添加分類Category:未被巡查的新页面的功能，若不希望{{未巡查}}被讀者看到，可以透過全站CSS將{{未巡查}}display:none，然後再添加個小工具只讓有啟用小工具的巡查員看到；對於樓下提到「巡查员需要另行移除未巡查模板，这是否客观上增加了巡查流程从而降低了巡查效率」可以修改TW工具，標記巡查模板時，自動移除{{未巡查}} (編輯 討論 說明  信息 鏈入 歷史)。-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月21日 (日) 18:45 (UTC)

(＊)提醒，与其挂标示，还不如动员多些巡查员去干活，而不是整天鸡蛋里面挑骨头。——路过围观的Sakamotosan | 避免做作，免敬 2019年7月21日 (日) 13:18 (UTC)

• (＊)提醒：谢Cohaf君在社群即时通讯平台的邀请，我个人实际上不赞成该提案，一些缘由已经与Cohaf君当面详陈。然而来此看，发现大家都支持此提案，故亦不表达其他意见，以干扰共识和公示，惟有几点伏请诸位编辑在完成公示通过方针前再略作考虑：
  • 经对原有“30日过期”原则思考，恳请考虑使用该模板虽在技术上不等同但实质上是否等同于将过期时限由30天延长为无限期，并具体有以下问题：
    1. 恳请是否考虑是否会略弱对巡查的时效性的执行：对未巡查30日过期的制度进行考察，该制度为巡查员对条目的巡查工作设定了任务期限，其中一个比较根本性的事由是，对于存有不当的新条目应当尽快处理，巡查工作是讲求失效性的。考虑到巡查工作并不是彻底解决问题的过程，除了提交侵权、速删、提删外，巡查工作更多的是通过加挂模板指明条目或其他页面存在的问题、将页面链接到wikidata使得各语言计划的维基互通等。因此巡查工作的性质就决定了，巡查工作并不应当是意向可以像存废讨论一样比较长时间等待以寻求共识的过程，而更多的是需要向潜在的读者作出适当的提醒或提供适当的服务。包括提醒他们条目或在协作的立场观点、或在依据的可靠性、或在其他方面是存于与维基百科普遍质量水平和要求不符的瑕疵的，是不能同其他条目等同看待或等同地从中接受知识或信息的；也包括帮助他们更方便、及时地在本语言计划条目内容不充分的情况下，尝试从其他语言计划获取信息。承上所言，未巡查的模板的使用，虽然是针对超出30天的过期条目，实质上保证了未巡查条目永不过期，绕过了30天过期的制度，是否削弱了对巡查时效性的强调，违背了30天过期制度设置的本意；
    2. 恳请是否考虑是否会削弱巡查的紧迫性：承上问，30日过期制度所设定的任务期限，客观上构成了未巡查条目超时不可逆的情况，这与巡查工作所要求的时效性是相吻合的，若未能及时为读者充分提示条目存在的问题或未能及时向读者提供依巡查工作方针所应向读者提供的服务或提示，其影响是随着时间也即随读者数量的增加而递增的。这种有急迫性的制度，以迫使巡查员重视即将过期条目的形式使得巡查工作尽量尊重了对时效性的要求。而承上所言，对30天过期制度的实质性绕过，通过令未巡查条目时时可以寻找、不必担心消失，使得这种紧迫性削弱，而这种削弱是否大大降低了30天过期制度设置所带来的好处；
    3. 恳请是否考虑是否会削弱对巡查过度谨慎性的制度限制：又观察实际情况，考虑到避免令有问题的条目未受到充分处理即被标记为已巡查，现有的制度要求巡查员以充分审慎的态度来巡查，对于存有一定疑问难以确定的条目，巡查员不应标记为已巡查。为确保该要求的实施，巡查员如果未以充分审慎的态度标记已巡查，可以会被申请除权。同时，基于维基百科历来的方针和精神，我们并不要求巡查员必定要巡查某个数量的条目。上述两项客观上一定程度导致了巡查员可能过度审慎，因为对疑难巡查作出决定并标记为已巡查，如引起争议客观上存在受惩的可能，而反之不点击已巡查则不会引起相关风险。30天过期制度实现的紧迫性，客观上使得对待巡查应尽速作出决断的要求作出了强调，由于过期条目的不可逆性客观上一定约束了过度谨慎。绕过了30天过期的制度，是否削弱了这种有益约束，而使得过度谨慎的情况进一步被鼓励。
  • 经对巡查积压问题进一步解决方案的思考，恳请考虑使用这些模板是否会削弱建立更根本解决积压问题的可能、条件或动机，具体为：
    • 恳请是否考虑使用该模板会削弱建立会商会审制度的基础：对于疑难巡查，承上考虑到巡查员的谨慎性倾向，通过本人将即将过期的条目，移交到开放任务telegram群会审的经验，一方面将即将过期的条目单独拿出提请大家会审，由于其将要过期的情况客观存在，其紧迫性使得大家相较一般的巡查疑难更为重视；另一方面，会商会审制度则削弱了单独巡查中承担责任的顾虑，听取大家的意见后巡查员更敢于审查，而过度审慎问题一定程度上化解。使用未巡查模板绕过了30天过期的制度，承上，削弱了巡查的紧迫性基础，也使得会商会审的重点目标条目范围扩大，使得这个可能能够建立起来的、能够在多方面从根本上提升巡查能力和速度的制度，实施的基础和动机大大削弱，最终不利于从根本上解决问题，即从巡查的数量和速度上提升。
  • 经对使用该模板实际执行巡查工作的思考，恳请考虑使用该模板是否会引起降低巡查效率的问题，具体为：
    1. 恳请是否考虑使用该模板会导致所提供消息不充分集中而降低巡查的效率或有技术问题：目前的巡查利用的是新页面列表，在该列表中充分给出了页面的创建者（是注册用户？是IP用户？是不是常见的破坏者？甚至可以通过js获知该用户是否为自动确认用户等）的信息、给出了条目或页面的简要内容、给出了编辑摘要、给出了标签，而通过模板将条目归入分类中巡查，这些信息都不在能够方便集中的呈现，这是否客观上降低了信息获取效率从而降低了巡查效率；
    2. 恳请是否考虑使用该模板是否会因模板运用流程而降低巡查的效率：目前利用TW的巡查是模板悬挂/提删/速删/侵权和标记为已巡查可一步到位的，而运用未巡查模板后，出加挂模板外，巡查员需要另行移除未巡查模板，这是否客观上增加了巡查流程从而降低了巡查效率；
• 综上所述，该模板的运用，在提升巡查速度、促进巡查方面本身没有特别直接的推动作用，而反过来可能存在削弱了原有制度的多项有益属性、乃至于可能为原有的巡查工作增加可能的牵碍。这其中有一些技术性牵碍，可能是直接将巡查过期期限加长至无限期能够避免的，这也说明，使用分类可能是比直接延期更存在疑问的选项。伏请众位是否考虑以上问题，再决定是否使用，谨表浅见。--Kirk★ 0讨论│图书馆0 2019年7月21日 (日) 18:23 (UTC)
  • (！)意見：稍微修改 TW 來在標記已巡查時自動刪除未巡查模板是很簡單的事。至於「提供信息不集中」的問題，在下能想到的最好辦法就是用機器人在分類頁面自動添加這些信息。 -- Vakrieger♀ 💢❤️🗯️ 2019年8月4日 (日) 09:20 (UTC)
• Cohaf私下里说写得太长，我们后来进行了一些其他方面的讨论，我这里提一个简单的——如果分类越积愈多（根据我昨天熬夜突击巡查5小时的经验，完全有可能），积到1000多个页面甚至更多，谁还想来碰呢。类似的情况也可以看看目前的一些积压的工作，个别分类有2000余条目之多。--Kirk★ 0讨论│图书馆0 2019年7月21日 (日) 19:45 (UTC)
• 站外与Krik君讨论了，其实就是要鼓励巡查员去巡查，基本有了设立巡查员奖的想法。--Cohaf(talk) 2019年7月22日 (一) 07:59 (UTC)

(－)反对:30天未按「已巡查」≠未巡查，其實新頁面很多巡查員都會看一下，只是未按「已巡查」，因為巡查工作必須很審慎，不能輕率地按下「已巡查」；相反，條目30天都很多巡查員看過都覺得沒問題，其實條目問題不是很大，我們加一個「未巡查」的模板，我看不到有甚麼意義？--蟲蟲飛♡♡→♡℃※留言 2019年7月28日 (日) 03:04 (UTC)

• 如果設立機器人給新條目直接加上{{未巡查}}行不行？然後設立過濾器只允許巡查員摘走此模板。30天後，放寬至任何自動確認用戶均可在確認條目無明顯問題後摘走模板。在下覺得這樣也可以激勵更多巡查員去做事 -- Vakrieger♀ 💢❤️🗯️ 2019年8月3日 (六) 04:54 (UTC)
• (？)疑問方針要不要直接規定{{未巡查}}模板只能由巡查員、管理員巡查完畢後才能移除?「未巡查的頁面在720小時（30天）後將不能被巡查。」跟「30天未被巡查的條目應掛上{{未巡查}}模版以提醒其他編者協助巡查。」；一個是30天以後不能巡查，另一個是30天以後掛上模板提醒編者巡查，這兩者不會有點矛盾嗎?--Bagakuco（留言） 2019年8月11日 (日) 15:30 (UTC)
  • @Bagakuco：系統三十天后無法使巡查員按下巡查扭，我們也無法從Special:NewPages中知道一個頁面是否還沒有巡查。這個分類只是要幫忙我們知道哪個頁面三十天了還沒有巡查，且提醒我們處理，即使我們無法實際上按下巡查扭了。--Cohaf(talk) 2019年8月11日 (日) 15:54 (UTC)
    • (：)回應這麼說是現行條文的說法有點籠統，至少跟巡查紐沒有關係。為了防止以後有其他人誤會，(＆)建議「未巡查的頁面在720小時（30天）後將不能被巡查。」修改成「未巡查的頁面在720小時（30天）後巡查員將無法使用紐標示為已巡查」之類的說明。--Bagakuco（留言） 2019年8月11日 (日) 16:21 (UTC)
      • @Bagakuco：謝謝您完成--Cohaf(talk) 2019年8月12日 (一) 06:25 (UTC)

设立维基巡查奖

为了鼓励巡查员勇于巡查，我们可以设立维基巡查奖，现在建议主空间巡查100次为1级，类似编辑奖。如果巡查员巡查权有被提交REVOKE而提醒，警告，停权，或者除权就不符。现在是主空间积压。如果其余空间积压也可以考虑。以上，谢谢。--Cohaf(talk) 2019年7月22日 (一) 07:58 (UTC)

• 赞成，级距也可为考虑200次或其他合适的数值，面向主条目空间能够一定程度上纠正目前巡查上的一些bias，巡查其他页面特别是Talk页面的人数相对较多（这一类页面巡查难度较低），条目的巡查是目前最为紧迫的。目前巡查工作已经成为中文维基百科一项任务比较重、需要受重视的工作，值得像编辑一样受到适当鼓励（特别是与工作效果有一定比例关系的那种鼓励）。--Kirk★ 0讨论│图书馆0 2019年7月22日 (一) 08:07 (UTC)
• (＋)支持 比用模板加分類 或 只加分類 的方案更能減低積壓-- 娜娜奇🐰鮮果茶☕（☎️·☘️） 2019年7月22日 (一) 08:21 (UTC)
• (＊)提醒，与其为解决问题而制造问题。请 去 干 活。——路过围观的Sakamotosan | 避免做作，免敬 2019年7月22日 (一) 08:45 (UTC)
  • @Cwek：個人覺得大章節下提醒一次就好，制度問題的解決同樣重要。（至於我，這兩天巡了2、300條目肯定是有了，巡查雞鴨多到爆炸）巡條目的人比巡其他頁面的人少，這是問題--Kirk★ 0讨论│图书馆0 2019年7月22日 (一) 09:15 (UTC)
• 單純只統計條目空間的巡查次數在技術上應該有困難。如要設立，建議擴展至所有空間。至於巡查條目為何較少，答案顯然易見，因為條目通常比較錯綜複雜，不時會出現一些難以判斷的個案。—AT 2019年7月22日 (一) 13:03 (UTC)
  • @AT：有工具可以算出，您巡查了23923條目。--Cohaf(talk) 2019年7月22日 (一) 13:27 (UTC)
    • 那我沒有意見。—AT 2019年7月22日 (一) 13:30 (UTC)
• (＋)支持，聽起來不錯，不過(＆)建議@Cohaf：把等級程度劃分一下，比如巡查了500個條目才升1級。不然像AT巡查的等級不就200級超過了?　巡查員大概的名單可以從這裡看的出來，而且一般用戶要申請巡查權也不用像人事任免一樣吧?--Z7504非常建議必要時多關注評選（留言） 2019年7月23日 (二) 16:24 (UTC)
• 努力巡查的可以給站務奬，不認為把站務數量當作直接榮譽是好的方式，如果巡查員追求數量每個都只作基本的巡查放行，那原本巡查慢但會認真校對全部來源與擴充條目的巡查員多外公平，能改善的巡查員是好的巡查員，求速度只掛模版的是普通的巡查員。--Zest 2019年7月24日 (三) 01:21 (UTC)
  • 其实巡查奖的问题是三个方面：
    1. “能改善的巡查員”的定位：“能改善的巡查員”确实非常鼓励，但改善一个主编擅长的条目通常要花10分钟以上（KirkLU在telegram直播改善氹仔轻轨车厂[3]），更不用说而目前待巡查中常积压的艺人、专辑、体育赛事条目，巡查员有时指出问题都棘手，更不用说改善。能改善很好，能坚持甚至可以提报站务奖，但这不是巡查员的尽职的唯一标准、最低要求。
    2. 巡查员的最低要求，巡查奖鼓励的方向：巡查的第一要务不是改善本身，而是将不符合方针（CSD、侵权）的内容及时排除，同时为其他条目的改善指明方向（修正轻易能改的表面错误+通过悬挂维护模板充分暴露条目存在的问题）。对于符合这些要求的巡查，即使是同类型条目大量巡查，也是有价值的。巡查奖一定程度上就是要鼓励巡查员在待巡查过期前完成巡查应完成的基础工作，这同时也是对条目改善工作的一种支持。
    3. 对于不合要求的巡查，是否有阻止和惩戒机制：上述巡查奖颁授制度规定了，被提交REVOKE而提醒、警告、停权或者除权，应不予颁授或褫夺巡查奖。对于屡次作出不符合要求巡查的巡查员，擅用除权制度即可。
  • 以上，巡查奖制度在鼓励巡查的同时，又能依托现有机制排除不当巡查（为刷次数而不达要求），我认为该制度可行、妥当，有利于巡查更为及时，也有利于通过暴露条目问题指明条目改善的方向。--Kirk★ 0讨论│图书馆0 2019年7月31日 (三) 06:50 (UTC)

(＋)支持:提案非常好，可以鼓勵巡查員處理站務。--蟲蟲飛♡♡→♡℃※留言 2019年7月28日 (日) 15:17 (UTC)

• (＋)支持：意見不錯，鼓勵一下巡查員。--KMB-ATENU139 2019年7月29日 (一) 03:37 (UTC)
• (＋)支持，但我覺得100次會不會太多了一點。不妨改成50甚至20次便升一級，給巡查員們看得見的進步。-- Vakrieger♀ 💢❤️🗯️ 2019年8月4日 (日) 09:13 (UTC)
• (＝)中立，不太贊成量化巡查。Richard923888 和我聊個天 2019年8月10日 (六) 16:33 (UTC)
• (！)意見：量化容易导致低质量巡查。可以按维基奖励那样。--Br₂ 2019年8月14日 (三) 02:23 (UTC)
• (＊)提醒大家，如果對設立獎項的標準已有共識的話，請別忘記最後要到維基百科:維基榮譽與獎勵/申請設立榮譽及獎項進行表決。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年8月18日 (日) 06:26 (UTC)
• (－)反对，上面有些已经提到，这个指标不确定或者主观化，例如如果以数量判断的话，对于认真协助改善的可能不公平，而且可以归并到站务奖中。另外部分赞同者如同拍手鼓掌橡皮章，或者还提出保留意见。综上，请给出针对上述问题更具体可执行的评判措施。——路过围观的Sakamotosan | 避免做作，免敬 2019年8月19日 (一) 00:50 (UTC)

不活躍巡查員

其實還有一個方法，類似Cwek的留言『请 去 干 活』。我看我們可以六個月沒有巡查條目空間一次的巡查員就除權。我們不需要Hat Collector。大家如何看? 參考數據會是類似User:Xiplus/巡查統計。--Cohaf(talk) 2019年7月23日 (二) 11:03 (UTC)

• 我這麼懶惰可能會首先被除掉 Orz大致支持，巡查員不是頭銜。不過一定要強迫那些不擅長巡查條目空間的人巡查條目嗎？某些人不一定是因為巡查條目麻煩而不去巡查，而是他們強項本來就不在巡查條目，而是模板等其他空間。（雖然其實有可能根本沒有這種人就是了）—— Eric Liu_{（留言．留名．學生會）} 2019年7月23日 (二) 14:52 (UTC)
  • 但是我可能就是这种人。。。# D 2019年7月23日 (二) 17:34 (UTC)
• (＋)支持，但其实个人觉得需要扩展到Template, Module, Wikipedia, Category（？）空间，不然可能波及到一般不巡查主空间而巡查其他空间的巡查员，但这一类的标准需要更严格，毕竟这一类积压一大堆，随便找几个分类或是导航模板就续命6个月还是不行，建议（若可能）主空间6个月或其他空间（非讨论页）2个月内没有巡查记录则除权。# D 2019年7月23日 (二) 17:34 (UTC)
  • User:DW_YoungDLS说的很有启发性，主空间6个月或其他空间（非讨论页）2个月内没有巡查记录则除权这个方案大致一看蛮好。不过仔细想，其实主空间也可以六个月续一次，进一步作大幅收紧可能也不好。进一步鼓励条目巡查的问题，倒是可以交由维基巡查奖。--Kirk★ 0讨论│图书馆0 2019年7月23日 (二) 18:43 (UTC)
  • 如果目的是减少backlog, 不觉得除权可以达到。~ viz ✪ 2019年7月23日 (二) 18:47 (UTC)
• (－)反对。不喜欢为了敦促人巡查，不巡查就取消你的权限这种感觉和氛围。我相信维基百科的权限理想是，所有人都能理性行事，因此应该给所有人所有权限。但是因为信任原因，因此改为只要确认你足够受信，就给你信的过的最大权限。受信与否，是权限授予的唯一指标，不应该把权限当作任何别的物品对待。Bluedeck 祝福香港 2019年7月23日 (二) 21:08 (UTC)
  • 比较认同。另外顺带一提，提案者本身就是巡查员，我认为其在这组议题所花的时间，足够把那些待巡查的页面都看一遍。——路过围观的Sakamotosan | 避免做作，免敬 2019年7月24日 (三) 00:30 (UTC)
    • (：)回應@Bluedeck：其实不巡查握有巡查权限也没有意义，但是其实不除权也没有大安全问题。@cwek：我也是吧全部可能的方案提出，比较容易讨论。另:也同意维基百科是自愿参与的，不能强迫别人做事情。--Cohaf(talk) 2019年7月24日 (三) 03:58 (UTC)
    • 这句话也太好笑了。一方面，不想解决问题反而想解决提出问题的人；另一方面，就让提案人一个人（或几个人）干活，不提问题来解决问题，让其他巡查员翘着二郎腿休息是吧？--Rowingbohe♬ 为利奇马中的受害者默哀（台州专题） 2019年8月11日 (日) 14:58 (UTC)
• 這比巡查獎還要爛，請問這和不活躍管理員除名有那些異同，為何不活躍管理員煮這麼多年社群不通過主要是依什麼，依的這個精神為何不是全部權限，而要把巡查單獨列出？回退呢？-Zest 2019年7月24日 (三) 01:13 (UTC)

(－)反对：認同USER:-Zest及User:Bluedeck的觀點，沒必要通過這樣的方式去強逼巡查員去巡查。也認同user:cwek的觀點，見上。--蟲蟲飛♡♡→♡℃※留言 2019年7月28日 (日) 15:37 (UTC)

• 其实可以在申请巡查员的时候，更多的授予临时权限，对于缺乏模拟巡查经验的，也可以在确认申请人对于相关方针有一定理解的情况下，考虑临时授权，并在这段时间中或结束后复检，一开始可以七天，后面管理员可以根据具体情况再进行判断，继续授予更长时间的临时权限/或暂不授权，要求申请人继续模拟巡查，直到有更多经验后，继续授予临时权限/或直接再授予长期权限--及时雨 ^留言 2019年8月9日 (五) 13:15 (UTC)
• @94rain：基本同意您的建议，我看这个是应对不活跃巡查员的一个办法。看看其它人如何说，我认为这个提案可行。--Cohaf(talk) 2019年8月11日 (日) 14:42 (UTC)

提議修訂WP:ILLEGIT

完成，無異議，修訂WP:ILLEGIT提案通過--Z7504非常建議必要時多關注評選（留言） 2019年8月20日 (二) 16:23 (UTC)

下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

---

WP:ILLEGIT中被視為濫用多重帳號的行為包含禁止編輯計畫頁面，那是不是分身不能更名？還是說只要在「使用者切勿使用多重帳號誤導別人、破壞及擾亂共識的形成」的前提下此種行為是被允許的？因為如果是WP:SOCK#LEGIT中被容許使用多重帳號的「保安」行為，那麼在他處也不就不能在計劃頁進行保安編輯？SmallTim 2019年7月27日 (六) 16:13 (UTC)

• 更名可以使用Special:全域重命名申请。禁止编辑计划页面en方针中说的是“未揭露的多重账号”，我们的方针未说明这一点，可以讨论看看是否可以加入这一点。我认为一个人的分身账号如果在签名中明确表示自己的主账号，不至于令他人混淆以为是另一个人，是可以参与讨论的，否则不应与主账号在同一个讨论中出现，参与其它讨论也至少要在用户页声明。--及时雨 ^留言 2019年7月30日 (二) 02:30 (UTC)

現行條文 偽造民意：多重帳號不應被用作捏造對某種觀點的支持，或誤導其他用戶。 編輯計畫頁面：多重帳號不應編輯計畫頁面，如修改方針和指引、參與存廢討論、申請成為管理員投票等。 規避規則：維基百科的各項方針和指引均以用戶，而非帳號為計算單位。例如回退不過三原則的三次回退限制，是指一個個人的回退次數，而不是指一個帳號的回退次數。如被揭發以多重帳號進行破壞行為，除了傀儡帳號被封禁外，主帳號也會因此受到處分。此外，被封禁的用戶也不應利用傀儡來避過封禁，繼續編輯和參與討論。如被發現，可能導致主帳號的封禁期限重新計算，甚至有可能被延長封禁期限。

提議條文 偽造民意：多重帳號不應被用作捏造對某種觀點的支持，或誤導其他用戶。 編輯計畫頁面：未公開的分身帳號不應編輯計畫頁面。此外，任何分身帳號皆不應在容易使人混淆身分的計劃頁面進行編輯，如修改方針和指引、參與存廢討論和任何投票等情況。 規避規則：維基百科的各項方針和指引均以用戶，而非帳號為計算單位。例如回退不過三原則的三次回退限制，是指一個個人的回退次數，而不是指一個帳號的回退次數。如被揭發以多重帳號進行破壞行為，除了傀儡帳號被封禁外，主帳號也會因此受到處分。此外，被封禁的用戶也不應利用傀儡來避過封禁，繼續編輯和參與討論。如被發現，可能導致主帳號的封禁期限重新計算，甚至有可能被延長封禁期限。

• 修正了部份描述，應為事實，附知@94rain。SmallTim（留言） 2019年8月4日 (日) 10:29 (UTC)
  • 七日无异议，开始公示。--及时雨 ^留言 2019年8月12日 (一) 01:27 (UTC)
  • 94rain君，個人建議將「未公示的分身帳號」改為「未公開的分身帳號」。--J.Wong 2019年8月12日 (一) 12:19 (UTC)
    • 這直接（代）改就好，完成。산모사 ^DC17_{GAN FLN1 FLN2} 2019年8月12日 (一) 15:38 (UTC)
      • 不过方针中原本就说的是#公示备用帐号，并且有链接指向那一章节，若改成“公开”，下面的章节标题是否需要一起改掉。--及时雨 ^留言 2019年8月13日 (二) 04:33 (UTC)
        • 改了，這是語病問題，可以事實性修訂。산모사 ^DC17_{GAN FLN1 FLN2} 2019年8月13日 (二) 06:47 (UTC)
        • 副ping@94rain該提案應已經通過，故關閉討論--Z7504非常建議必要時多關注評選（留言） 2019年8月20日 (二) 16:23 (UTC)

---

本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

木兰宽松许可证第1版授权的内容可否复制到维基百科？

今天看到中国开源云联盟发不了国内的第一个开源协议，所以想问一下，这个协议授权的内容可否复制到维基百科？——Huangsijun17（留言） 2019年8月7日 (三) 02:05 (UTC)

• @Taiwania Justo。산모사 ^DC17_{GAC FLC} 2019年8月7日 (三) 04:10 (UTC)
• 此协议应当符合OSI的开放源代码定义。--云间守望🕯🕯 2019年8月7日 (三) 06:47 (UTC)
• 粗略看了一下感覺就比 MIT 限制多一點點。但以這個授權的作品都主要是軟件吧？-- Vakrieger♀ 💢❤️🗯️ 2019年8月7日 (三) 14:25 (UTC)

• 考虑某些软件的帮助文本和说明文本等可能会被复制到维基百科，因故请各位讨论。——Huangsijun17（讨论） 2019年8月10日 (六) 06:56 (UTC)
• 只要符合「可任意修改並使用於任何用途」、「可商業使用」這兩大項的授權條款，皆能相容於維基媒體。臺灣杉在此發言 (會客室) 2019年8月14日 (三) 09:00 (UTC)

参考資料

消歧義頁的有效連結

我希望在這裏取得社群對於消歧義頁的有效連結的定義，以及消歧義頁應有的有效連結數的意見。我個人認為：

1. 藍連（包括指向相關内容的重定向）是有效連結；
2. 綠連是有效連結；
3. 紅連不是有效連結；
4. 消歧義頁應有≥1個有效連結；

以上。산모사 ^DC17_{GAC FLC} 2019年8月8日 (四) 00:40 (UTC)

• (＋)支持，但就中文維基百科的現實情況，只有1個有效連結的消歧義應該也要允許。-- Vakrieger♀ 💢❤️🗯️ 2019年8月8日 (四) 05:06 (UTC)
• (－)反对：1個有效連結甚至全部都是紅連應該也要允許，只要消歧義的內容能提供有用資訊，有效連結的數量不應該是絕對的參考標準。--Opky9407（留言） 2019年8月8日 (四) 07:06 (UTC)
• 請大家留意：我這裏並不是要提出甚麼提案（雖然之後可能會根據結果而提出提案），我希望各位是對以上四項表示認同與否，而不是表示支持／反對。산모사 ^DC17_{GAC FLC} 2019年8月8日 (四) 07:37 (UTC)
  • 就是不認同第4點。--Opky9407（留言） 2019年8月8日 (四) 07:48 (UTC)

你既然放在方针版，是否意味着这不只是征集意见？我认为这些意见都比较合理。——路过围观的Sakamotosan | 避免做作，免敬 2019年8月9日 (五) 00:35 (UTC)

放在這裏的原因純粹是因為這個話題與方針相關。未來我可能會基於這個話題所收集得來的意見來發起新提案。산모사 ^DC17_FLN 2019年8月9日 (五) 01:44 (UTC)

• (－)反对第4点。这里有一个问题：红链的价值是什么？我认为在主空间（不仅是消歧义页），红链用来标明一个关注度足够的尚未有条目的概念。如果这个判断是对的，那么消歧义页可以仅有一个有效链接。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2019年8月9日 (五) 04:00 (UTC)

(？)疑問：您的「>1個」究竟是「≥1個」(至少1個)，還是「≥2個」(至少2個)呢？既然是整數，就應該使用「≥」，而不是「>」，以免造成溝通上的誤會。當然，如果以中文代替數學符號會更好，我極少看到"≤≥<>≠"出現在中維的方針與指引或是中華民國法律中。-游蛇脫殼/克勞棣 2019年8月9日 (五) 04:56 (UTC)

User:克勞棣由於連結的數量必須為整數，「>1個」其實就是「≥2個」。但最近我思考了一下，我認為有效連結只有一個應該也沒大問題，那我就給改成「≥1個」。副知@Vakrieger、Opky9407、Cwek、UjuiUjuMandan。산모사 ^DC17_FLN 2019年8月9日 (五) 10:23 (UTC)

支持。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2019年8月14日 (三) 04:20 (UTC)

• (＋)支持：提供簡單資訊不是消歧義的功用；應該有至少一個有效連結。--【和平至上】💬📝 2019年8月12日 (一) 17:32 (UTC)
• (－)反对：提供簡單資訊是消歧義的功用；那怕是0個，只要資訊是有用的，有多少個不是很重要。--Maccomcre（留言） 2019年8月14日 (三) 12:55 (UTC)
• (－)反对，假設某個消歧義頁有10個藍連，如果證實那些藍連全部其實都是無關的或對讀者無用的，那就算有10個藍連都要刪；反之，如果全是紅連但對讀者有用的，那其實都應考慮保留。本案對於「有效連結」的定位本身就有問題。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年8月14日 (三) 23:13 (UTC)
  • User:Cdip150“消歧義頁面只有一個目的，就是讓讀者可以選擇同名不同義的條目”，我想順道問一下，現在enwiki的指引還有沒有這一句？是“A disambiguation page is a non-article page that lists and links to encyclopedia articles covering topics that could have had the same title.”這句嗎？산모사 ^DC17_{FLN1 FLN2} 2019年8月15日 (四) 07:36 (UTC)
  • 另外，我也澄清一下：與相關内容無關的任何形式的連結在這裏不當成連結。산모사 ^DC17_{FLN1 FLN2} 2019年8月15日 (四) 07:45 (UTC)
    • 這樣的做法更奇怪：人就是人，不能說在某個環境下他不是人，連結也是一樣道理，衹要它是連結，任何情況都是連結；明明是連結卻又不當是連結，有指鹿為馬之虞。敝人這裏要指出的是「本案對於『有效連結』的定位本身就有問題」，不應單純以顏色來定義「有效連結」，又或者說：藍鏈不一定全部都是有效，而相對的，紅連也不一定全部都是無效。紅連實際上也可以是一種選擇（讓人選擇創建條目），與您援引的條文並不相違。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2019年8月18日 (日) 06:21 (UTC)
      • 傷人可以在某些情況下不當成傷人處理（這是中國大陸法制，是有些難理解，如果有中國大陸用戶能詳細解釋一下的話會更好），所以我照搬了這個道理來VPP。另外，我非常不認同閣下將「讓人選擇創建條目」視為「選擇同名不同義的條目」的觀點，原條文非常明顯沒有閣下所指的意思。산모사 ^DC17_{FLN1 FLN2} 2019年8月20日 (二) 00:26 (UTC)
• 独立消歧义页的主要作用是指向而非解释，解释只是为了更好地区分指向，所以不应该以是否信息为判断标准，而有效的目的链接。所以无论有多少解释，只看有效目的链接，原则上大于2个为佳（因为少量的话可以在同主命名的页面互相标识），但至少大于1个。——路过围观的Sakamotosan | 避免做作，免敬 2019年8月15日 (四) 09:31 (UTC)
• 我认为关注度是有效链接的必要条件。假如把“有效链接”定义为具备充分关注度的链接（不区分红链、蓝链、绿链）的话，消歧义页应至少有2个有效链接和1个蓝链。 --ᡠᠵᡠᡳ^Ujui ᡠᠵᡠ^Uju ᠮᠠᠨᡩ᠋ᠠᠨ^Mandan 2019年8月19日 (一) 01:58 (UTC)

技術

左上角維基球跳轉

於Phabricator查看
編號T229379的任務

通常只要按左上角的維基球，就可以隨時跳回WP:首頁，但是最近卻發現有時會跳到首頁，有時又跳到WP:首頁，求解，謝謝。--채진이야·TWICE❤·One In A Million ! 2019年7月30日 (二) 12:24 (UTC)

估计是部署的时候出bug了。看了一下Wikipedia:首页和首页的wgIsMainPage，两个都是true--百無一用是書生 (☎) 2019年7月31日 (三) 03:07 (UTC)

不只是这个问题，现在条目空间标题下面以前是显示我们站点口号的，现在只剩下“来自Wikipedia”（看7月30日之前没被修改过的条目，应该还保留之前的HTML解析缓存数据），要么就是类似部署的问题，也可能是translatewiki又给人乱改了？——路过围观的Sakamotosan | 避免做作，免敬 2019年7月31日 (三) 03:31 (UTC)

这些应该都是同一个问题造成的，我觉得是部署出的问题，不是translatewiki。除了这两个页面，其他页面标题下面都正常显示站点口号。另外首頁的浏览器标题栏只显示“Wikipedia”，没有了页面名称，和WP:首頁一样了（其他页面正常）。--百無一用是書生 (☎) 2019年7月31日 (三) 03:50 (UTC)

可以复现。怀疑是PHP7实例和其他实例的配置不一样，导致出错。~ viz ✪ 2019年7月31日 (三) 08:09 (UTC)

找了半天没找到如何取消PHP7--百無一用是書生 (☎) 2019年7月31日 (三) 12:47 (UTC)

目前是随机的，不过Phab那边有人提到WikimediaDebug，可以用来切换。~ viz ✪ 2019年8月1日 (四) 22:58 (UTC)

搜索框的「搜寻Wikipedia」是不是也跟部署有关系。--Hamish沉痛悼念唐山大地震遇难者 2019年7月31日 (三) 15:42 (UTC)

• 我剛剛點首頁的時候竟然出現了首頁條目的標題跟WP:首頁的內容混在一起的詭異現象== —— Eric Liu_{（留言．留名．學生會）} 2019年8月1日 (四) 05:07 (UTC)
• 常常維基百科，自由的百科全書都會變成Wikipedia-- Sunny00217 2019年8月8日 (四) 06:42 (UTC)
• 實在話，這個問題到現在似乎還存在著尚未解決?--Z7504非常建議必要時多關注評選（留言） 2019年8月9日 (五) 12:26 (UTC)
• 實在是...-- Sunny00217 2019年8月10日 (六) 14:49 (UTC)

本章節暫時不存檔（直到phabricator修復）。移除{{Do not archive}}以讓機器人存檔。留言請置於本模板上方。

部分缩略图会返回content-type: application/x-www-form-urlencoded导致无法在Chrome正常显示

於Phabricator查看
編號T188831的任務

如下这个缩略图：

在Chrome里无法正常显示，刷新缓存也没用。

研究后发现是这个缩略图（图像地址：https://upload.wikimedia.org/wikipedia/commons/thumb/8/8a/Shin-marunouchi.Building-2007-01.jpg/100px-Shin-marunouchi.Building-2007-01.jpg ）不知道为何会返回 “content-type: application/x-www-form-urlencoded”的header，而不是正常的“image/jpeg”，从而导致

1. 如果直接打开图片，不会在浏览器里直接显示，而会触发下载（Chrome和Firefox都会）
2. 在Chrome的<img>tag中无法正常显示（Firefox正常）。

--小烈 (找我?) 2019年7月31日 (三) 22:45 (UTC)

我在chrome里能打开，mime类型也正常，但是点击后会下载--百無一用是書生 (☎) 2019年8月1日 (四) 03:03 (UTC)

chrome里看这个缩略图的header信息，content-type是image/jpeg，但是curl的话则是x-www-form-urlencoded--百無一用是書生 (☎) 2019年8月1日 (四) 03:10 (UTC)

这里不正常： https://i.imgur.com/dzX7IYo.png --小烈 (找我?) 2019年8月1日 (四) 05:20 (UTC)

你这个截图，我这里同样位置是150px的缩略图，图片显示没问题。但是你给的100px的这个的确有问题--百無一用是書生 (☎) 2019年8月1日 (四) 06:17 (UTC)

其实就是同样的[[File:Shin-marunouchi.Building-2007-01.jpg|alt=Shin-Marunouchi Building|100px]]语法，但是你生成的缩略图是100px的，而我生成的是150px的...--百無一用是書生 (☎) 2019年8月1日 (四) 06:19 (UTC)

原来如此，可能你系统或者浏览器设置的150% scale吧。--小烈 (找我?) 2019年8月1日 (四) 06:30 (UTC)

我系统是125%,浏览器是100%。难道是显示器分辨率不同造成的缩略图大小不同？--百無一用是書生 (☎) 2019年8月1日 (四) 12:42 (UTC)

对的，如果系统设置了125%，浏览器也会自动对网站缩放到125%。High-DPI对应的网站会自动调用高分辨率的图像素材（否则就是100px硬拉成125px，会很模糊）。--小烈 (找我?) 2019年8月1日 (四) 17:52 (UTC)

[[File:Shin-marunouchi.Building-2007-01.jpg|alt=Shin-Marunouchi Building|100px]]生成的缩略图是 https://upload.wikimedia.org/wikipedia/commons/thumb/8/8a/Shin-marunouchi.Building-2007-01.jpg/150px-Shin-marunouchi.Building-2007-01.jpg --百無一用是書生 (☎) 2019年8月1日 (四) 03:30 (UTC)

• 我也是用Chrome，可是點選了也沒發現什麼問題？—— Eric Liu_{（留言．留名．學生會）} 2019年8月1日 (四) 05:09 (UTC)
• 不应该呀，你贴那个不是150px吗？--小烈 (找我?) 2019年8月1日 (四) 05:13 (UTC)
  • 点这个：https://upload.wikimedia.org/wikipedia/commons/thumb/8/8a/Shin-marunouchi.Building-2007-01.jpg/100px-Shin-marunouchi.Building-2007-01.jpg --百無一用是書生 (☎) 2019年8月1日 (四) 06:15 (UTC)
• 我的Chrome可以正常顯示100px的，類型一樣是x-www-form-urlencoded，連結也會觸發下載。-- tang891228 _留⁠言 2019年8月1日 (四) 21:16 (UTC)

这个图片的100px缩略图，如果是连接的话是会被当成下载处理，但img里面没发现加载失败。chrome 75.0.3770.142 。——2019年8月2日 (五) 00:14 (UTC)

就因为是mime错误，所以才会点连接下载--百無一用是書生 (☎) 2019年8月2日 (五) 03:13 (UTC)

mine是一个问题，看上去需要服务器那边刷新文件缓存来重置，至于chrome的话，我的版本的img的显示看上去没问题。——路过围观的Sakamotosan | 避免做作，免敬 2019年8月2日 (五) 03:37 (UTC)

请问你右键复制图像地址，确认是100px吗？有可能和Shizhao一样并没有真的返回100px的图。另外我的chrome是Version 76.0.3809.87 (Official Build) beta (64-bit)，也可能是beta版导致的不同。--Fireattack（