跳至內容

維基百科討論:重定向/存檔3

頁面內容不支援其他語言。
維基百科，自由的百科全書

純簡繁重定向有必要麼？

本主題或以下段落文字，移動自Wikipedia:互助客棧/技術。執行者：Jimmy-bot（留言） 2016年7月4日 (一) 16:42 (UTC)。

純簡繁字差異的簡繁重定向（比如維基百科重定向到维基百科）有必要嗎？搜索框中鍵入繁體的「維基百科」，即使繁體的維基百科頁面沒有建立，也會自動跳到實際標題為簡體的维基百科條目上。頁面上有繁體的連結也是一樣，即使繁體的頁面沒有建立，也會自動糾正連結到實際標題為簡體的條目上，而不會留紅鏈（{{簡繁重定向}}中提到的「系統出錯時的紅字問題」應該不存在了吧？）。為何還有那麼多簡繁重定向Category:簡繁重定向{{簡繁重定向}}？我覺得技術上已經不需要純簡繁重定向了，當然除非頁面有歷史需要保留重定向頁，否則憑空建的純簡繁重定向頁沒必要吧？--Tomchen1989（留言） 2016年6月9日 (四) 01:15 (UTC)

或者假如有必要存在，也應該是bot自動給維基百科上的所有條目建立純簡繁字差異的簡繁重定向頁才對，手動建的話真的挺怪。--Tomchen1989（留言） 2016年6月9日 (四) 01:22 (UTC)

不久前曾經有過詳細討論：Wikipedia:互助客棧/其他/存檔/2016年1月#提刪繁簡重定向，目前在技術上確實有必要。--Wcam（留言） 2016年6月9日 (四) 01:29 (UTC)
當時給出的理由是，轉換系統可能不可靠，所以不應該完全依賴轉換。我覺得這個理由很站不住腳。—Chiefwei（論 - 歷） 2016年6月9日 (四) 02:20 (UTC)
站不住腳+1。難道還要為每個lua模板做一個解析器函數備份嗎？搞不好lua有一天也會壞哦。 --達師 - 334 - 554 2016年6月10日 (五) 14:03 (UTC)

這個問題最早在2014年就有討論（Wikipedia_talk:繁簡處理#「簡單的」繁簡重定向的創建與刪除問題），社群普遍是支持刪除的。L大的看法則是維持現狀，不要新建。—Chiefwei（論 - 歷） 2016年6月9日 (四) 02:24 (UTC)

Special:搜索壞的時候有用，但是反正也能找到正確的條目，簡繁重定向就真的沒用了，還會導致導航模板無法加粗等問題。#ForeverLove — 凡人丶 你一定要好好的 中文字數統計工具 2016年6月13日 (一) 12:08 (UTC)

要說系統出錯給備份方案，但哪天登陸系統出錯了怎麼辦？IP用戶大量破壞，管理員無法登陸刪除？還有mediawiki萬一將來有bug，搜索框搜不到特定條目怎麼辦？討論應該建立在當前的系統狀況下，不要說未來可能XXX。--Gqqnb（留言） 2016年6月22日 (三) 18:46 (UTC)
刪除繁簡重定向對於wiki系統並不會有什麼特別的益處。有用戶可能認為「刪除」後可以減輕系統負擔或騰出存儲空間，所以支持「刪除」。但「刪除」操作並不會如此，反而還會多出一個刪除日誌。Lianget認為維持現狀，不再新建倒是最優的選擇。而這個討論反覆出現，可能是這種誤解還一直存在於許多用戶腦海中，還是在WP:重定向中寫明關於繁簡重定向存廢的處理方法和原因吧。@Tomchen1989、Wcam、Chiefwei：@hat600、FRDian、Gqqnb：烏拉跨氪 2016年6月23日 (四) 17:07 (UTC)
當然，從資料庫角度確實增加了數據項，而不是減少。但是搜索時卻可加快速度，因為只搜索未刪除的條目。若我理解有誤請指正。--Gqqnb（留言） 2016年6月23日 (四) 18:24 (UTC)
在有重定向的情況下，繁簡錯誤的selflink不會自動加粗。而且如果從系統設計者的角度上說顯然不加粗是feature。 --達師 - 334 - 554 2016年6月24日 (五) 05:11 (UTC)

看許多年前的討論，不做繁簡重定向會有這些技術問題：

  1. 編輯摘要會出現紅字
  2. 仰賴繁簡轉換系統，運作負擔比繁簡重定向高
  3. 條目超過某個長度後，連結不會轉換

希望繁簡系統方面的人可以解釋一下這些技術限制。@Cdip150、鸟甲、SElephant：--113.52.81.182（留言） 2016年6月24日 (五) 02:23 (UTC)

Special:需要的頁面--Antigng（留言） 2016年6月24日 (五) 03:07 (UTC)

搜索也是大問題，比如條目的標題以及正文中出現的某關鍵詞都是用繁體撰寫的話，用簡體搜索這個關鍵詞，是無法搜索到這個條目的。而純繁簡重定向能夠幫助搜索匹配到條目標題中出現的、另一種「體」的關鍵詞。Template:技術問題中目前已經列出「T77967 Special:Search的繁簡轉換問題（可能是偶然現象）」，但他說「可能是偶然現象」，不對啊這絕對不是偶然現象。--Tomchen1989（留言） 2016年6月24日 (五) 12:37 (UTC)

無法重定向至Special:隨機頁面

本主題或以下段落文字，移動自Wikipedia:互助客棧/求助。執行者：Jimmy-bot（留言） 2016年8月24日 (三) 16:42 (UTC)。

提交的維基人及時間：--(留言) 我要真普選 Asdfugi留言於香港特別行政區。 crashchrome.com{{替代: 2016年8月14日 (日) 01:17 (UTC)

可能特殊頁不能重定向過去？——路過圍觀的Sakamotosan 2016年8月14日 (日) 02:48 (UTC)
From enwiki: "Note that redirects to other Wikimedia projects, other websites, or special pages do not work."，重定向至其他維基媒體計畫、其他網站或是特殊頁的話是無效的。--Steven™ ∴Message∵ 2016年8月14日 (日) 14:17 (UTC)

中英混用的外語重定向問題

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2016年10月28日 (五) 00:42 (UTC)。

以外文為主加一個中文表意文字的外文專有名詞重定向是否該建立是需要近一步討論的，在WP:RDRNC「學術名稱：科學用語、電腦技術等的專門用語、動植物的學名，這些詞語是字典裡查不到的」中只有提到全外文的學術名稱可以建立其重定向，但沒有講明以外文為主加一個中文表意文字的外文專有名詞重定向是否合適，且也有混用被刪除的案例，比如Wikipedia:頁面存廢討論/記錄/2016/09/09#Szilassi多面體，因此發起此討論--　宇帆（普通留言·Flow留言·聯絡） 2016年10月16日 (日) 17:43 (UTC)

毛主席，蔡總統等名稱

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2016年11月12日 (六) 08:42 (UTC)。


最近在AFD有一些與「毛主席」，「蔡總統」等標題的討論，問題包括是否需要重定向消歧義（例如蔣總統）還有蔡總統，馬總統，陳總統等名稱是否適合做重定向。Ping一下相關用戶 (@Nivekin、Shwangtianyuan、Wikijjj0001、和平奮鬥救地球、Kerolf666： @南极的熊、逆襲的天邪鬼、Lily135： --Champion 討論 民國105年 2016年10月31日 (一) 06:19 (UTC)

就不能打全名嗎？未來出了另一位馬、蔡總統又怎麼辦？我的想法是條目內也不會用到或極少可能用到的重定向應該刪掉。—AT 2016年10月31日 (一) 10:40 (UTC)

增加重定向的最低中立性要求？

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2017年3月16日 (四) 16:42 (UTC)。

這是「五星血旗」頁面的存廢討論入口，這個重定向定到中華人民共和國國旗，被大多數編輯共同認可為不中立。在網上搜索之後[1]，確實發現不少使用這一名稱指代國旗的情況，並且這些情況也確實都是負面的，可是，中維沒有禁止不中立重定向。我就此情況認為，保留是沒問題的。不過再想一想，假設有一天，很多人開始使用「冒牌國」來指代某個國家，那麼要不要把「冒牌國」重定向給這個國家呢？換句話說，重定向目前不要求中立，並且也有很多不中立的重定向有他們的價值。不過，是否應該對重定向加上一個比一般條目中立水平略低，但仍然存在的中立標準呢？Bluedeck excited 2017年3月1日 (三) 18:35 (UTC)

中文裡面為對手方冠以貶義代稱的行為其實很常見。如「偽滿洲國」、「共匪」、「蔣幫」等。「五星血旗」似乎起自法輪功媒體（來源搜索： "五星血旗" —Google：網頁、新聞、書籍、學術、圖片；百度：網頁、新聞、圖片；知網工具書）。--菲菇＠維基食用菌協會 2017年3月1日 (三) 18:53 (UTC)
如果目標條目中沒有相關重定向的描述，單純只是一個創建重定向行為的話，可能是會視乎用語的褒貶來判斷，不管是不是有來源。像WP:重定向中，提及en一個老例子「Dubya」作為重定向至「小布什」是來源於其口癖，至少要在文中描述，或者能夠直接體現（例如一些長名稱的縮寫）。——路過圍觀的Sakamotosan 2017年3月2日 (四) 00:31 (UTC)
有可靠來源使用就可以了吧，無關中立--百無一用是書生 (☎) 2017年3月2日 (四) 03:58 (UTC)
我覺得這個重定向最大的問題恐怕不是非中立，而是關注度：這麼用的人實在實在太少了。我傾向刪除，但我反對存廢討論中大部分的刪除理由：不能因為一個名稱或內容反對某個實體組織，就投票刪除它：這是WP:CENSOR。--菲菇＠維基食用菌協會 2017年3月4日 (六) 19:03 (UTC)
"五星紅旗迎風飄揚，勝利歌聲多麼響亮"...中國得有多少人會唱這個。可靠來源裏用的確實少是真的。--Innocentius Aiolos 2017年3月4日 (六) 19:46 (UTC)
然而我們得講邏輯和講規則，而不是在刪除與否上講感情。--菲菇＠維基食用菌協會 2017年3月4日 (六) 20:48 (UTC)

是否應該讓國外名人的人名重定向？

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2017年4月8日 (六) 00:42 (UTC)。

本節達成共識，請參與下方方案討論。

使用中文維基一個比較不完美的地方我感覺就是英文重定向中文數量太少，其中最明顯的就是對於名人的人名重定向數量太少。根據我這兩天15小時+的測試，大約60%的有代表性的英文名人都無法重定向。舉一個例子，拿破崙的英文Napoleon，放入中文維基搜索時出來的結果很不理想。Alfred Adler，New York University，Kathleen Norris, Fannie Hurst, Ida Tarbell, Albert Payson Terhune, Rupert Hughes這些詞用英文wiki是直接進入的我認為在中文wiki上也應該需要直接進入。我的想法是對於代表性非常強的人名應該要加入重定向，沒有搜索到中文條目的轉鏈進入英文wiki或者選擇讓用戶創建。並且在英文重定向中文的總體數量需要增加（在西方人名，地名，事件上等有代表性的英文詞）。第一次寫提案，寫的非常草率，希望大家能補充，謝謝！--Py930828（留言） 2017年2月13日 (一) 02:46 (UTC)

目前非中文重定向方針貌似尚未規範到外文人名的部份。之前的討論有Wikipedia:投票/非中文重定向頁面和Wikipedia:投票/非中文重定向頁面第二次投票。前者似乎未達成共識，後者則未論及此部分。如各位認為有需要，或許可就此方面議題進行討論（外文人名、名詞等重定向）。-和平、奮鬥、救地球！（留言）歡迎加入維基Telegram群 2017年2月13日 (一) 03:02 (UTC)
(～)補充：這位新手曾在IRC-TG群與各QQ群提問，表示使用搜尋功能輸入外文時，會顯示該條目尚未被創建，使其產生疑惑與不便（如果我的理解沒錯的話）。或許這方面也要考慮一下讀者和新用戶的感受與方便性，並做對應之調整（若技術上可行）。-和平、奮鬥、救地球！（留言）歡迎加入維基Telegram群 2017年2月13日 (一) 03:04 (UTC)

一點舊討論

非簡寫的英文重定向

--Temp3600（留言） 2017年2月17日 (五) 10:45 (UTC)

既然大家（大約共識見[3]）認為模版可以（有人甚至認為應該）用英文，何以同樣方便大家 －更方便讀者－ 的英文重定向如此多反對者？* : -) ---Hillgentleman | 書 | 二零零七年七月二十一號（星期六）格林尼治 07時43分28秒。
Hillgentleman提到「英文重定向」，我認為不能與「簡稱重定向」相提並論。例如將orange重定向到橙，這是「英文重定向」，似乎有過份濫用之嫌；但例如將OJ重定向到橙汁，這是「簡稱重定向」，只要大家認同「OJ」是常用的簡稱，重定向是可以接受的。 -- Kevinhksouth (Talk) 2007年7月21日 (六) 07:51 (UTC)
Kevin「似乎有過份濫用之嫌」<---似乎？請你講清楚，濫用就是濫用，然則請舉理由。何謂「濫」？* : -) ---Hillgentleman | 書 | 二零零七年七月二十一號（星期六）格林尼治 07時56分59秒。
橙的命名不是起源於英文為母語的地區，假如仍容許英文作重定向，那麼法文、德文、義大利文等為何又不能作重定向呢？總之，我的立場是歡迎「簡稱重定向」，但對不必要的「英文重定向」有所保留。 -- Kevinhksouth (Talk) 2007年7月21日 (六) 08:04 (UTC)
「為何又不能」??? 能! 請自便--> en:wikt:orange#Translations。
Kevin請回答：何謂「濫用」？* : -) ---Hillgentleman | 書 | 二零零七年七月二十一號（星期六）格林尼治 08時10分29秒。
我所指的「濫用」是指建立不必要的重定向的行為。根據Wikipedia:投票/非中文重定向頁面第二次投票，只有一些特定的情況下（也就是在該次投票中由社群通過的那幾個情況），非中文重定向頁面才可被建立。因此，將orange重定向到橙實屬不必要。反而根據社群共識，學名Citrus sinensis重定向到橙是可以接受。 -- Kevinhksouth (Talk) 2007年7月21日 (六) 08:39 (UTC)
「不必要」？維基 有很多物事都不「必要」。重要的是 有 無 用。 無論如何 有用無用，必要不必，亦非你Kevin一言而決。若有英國人，初學中文，想知orange 的中文是甚麼，則他可用orange之重定向。另外，我們在歐美有很多用戶，有時他們所在的網絡無中文輸入，則他可用orange之重定向，比要用網上中文輸入方便得多。* : -) ---Hillgentleman | 書 | 二零零七年七月二十一號（星期六）格林尼治 08時52分47秒。
「若有英國人，初學中文，想知orange 的中文是甚麼」，我認為他應該先到英文維基百科輸入orange，再在「其他語言」一欄點選「中文」進入中文維基百科的橙。 -- Kevinhksouth (Talk) 2007年7月21日 (六) 08:57 (UTC)
Kevin你知道工程中 redundancy 之重要嗎？若英文維基暫停又如何？* : -) ---Hillgentleman | 書 | 二零零七年七月二十一號（星期六）格林尼治 09時02分58秒。
你也有你的道理。也許我們兩人先暫停爭論，聽聽其他人的意見吧。畢竟在中文維基百科，向來都沒有「為任何條目的英文名稱建立重定向」這個習慣。假如經社群充份討論後主流共識是接受這種做法，我當然尊重並不會阻止。 -- Kevinhksouth (Talk) 2007年7月21日 (六) 09:08 (UTC)
我未見有人有興趣「為任何條目的英文名稱建立重定向」。現在我們講的是有用而無害的外語重定冋（即在任何情況下都不會誤導）可留。所以很難理解你可能會阻止那一種做法。* : -) ---Hillgentleman | 書 | 二零零七年七月二十一號（星期六）格林尼治 09時19分28秒。
你誤解了我的說話，我的意思是讓社群決定是否容許建立這類重定向。再拿回之前的討論作例子，外語國家名稱的重定向是被社群否決容許的，難道這類重定向是因為有「誤導」成份而被社群反對嗎？ -- Kevinhksouth (Talk) 2007年7月21日 (六) 09:28 (UTC)
我插一句，目前的票數說明「社群否決容許」(即沒有產生是否存刪的共識)是對的，但不能說明「社群反對」「這類重定向」。— fdcn talk 2007年7月22日01:18 (UTC+8 7月22日09:18)
我無誤解你的說話；我根本不知你在說甚麼。『難道這類重定向是因為有「誤導」成份而被社群反對嗎？』－明知故問。請回到該討論頁討論這事。* : -) ---Hillgentleman | 書 | 二零零七年七月二十一號（星期六）格林尼治 09時39分45秒。
提刪[4]人指 {{d|這是中文維基，沒有需要的重定向。}} 。吾人有template:速刪，同樣重定向到template:delete 。這是中文維基，Thomsonlee反而用英文模板提刪。* : -) ---Hillgentleman | 書 | 二零零七年七月二十一號（星期六）格林尼治 07時54分41秒。

我依然希望維基人都看一看上面提及的投票和討論，作為定位技術的重定向，非中文本身不應有「濫用之嫌」，是多多益善的。— fdcn talk 2007年7月21日07:59 (UTC+8 7月21日15:59)

另外一個說法，假使重定向並不佔有多少資料空間，何以為了自認的「不必要」而犧牲讀者的「方便性」？:)--春日クリス 2007年7月21日 (六) 09:12 (UTC)

覺得討論太多的話不妨從Wikipedia:投票/非中文重定向頁面第二次投票#快速刪除的標準開始看起。--RalfX（議） 2007年7月21日 (六) 09:20 (UTC)

  • 就事論事，「orange」重定向到「橙」是錯誤的，按英語論，還有桔子，橙色等其他含義，其他語言可能還有其他解釋，除了「方便性」，作為百科全書，還需要「準確性」
  • 建議多參考Wikipedia:投票/非中文重定向頁面第二次投票
—Isnow 2007年7月21日 (六) 09:22 (UTC)
同意。多謝提醒。Orange在英文維基百科是釋義頁。早前我們想得太抽象。* : -) ---Hillgentleman | 書 | 二零零七年七月二十一號（星期六）格林尼治 09時26分40秒。
至少我覺得本來就是外國的東西是可以允許使用簡稱重定向的，但是外文重定向是沒有必要的。例如說新加坡的地鐵，在新加坡幾乎所有的中國人去坐的時候不會說去坐地鐵，反而都會說去坐MRT，這個時候，MRT已經作為這個事物的另外一個名字被廣泛使用了，所以應該重定向。但是它的全名卻沒有必要重定向，因為那應該是英文維基的內容。—人神之間擺哈龍門陣 2007年7月21日 (六) 13:22 (UTC)
全名為什麼在中文維基沒有必要？有人需要它來定位中文地鐵的條目。請給出不必要的根據。這問題以前討論過很多次了。— fdcn talk 2007年7月21日15:10 (UTC+8 7月21日23:10)
我的理解是既然他需要用英文來定位中國地鐵，那麼他必定可以找到相關語言的百科全書，再通過該頁上的連結到中文維基。可以說得例子是，英文維基沒有很多可以使用的中文重定向，那我們也想用中文來定位它的一些條目阿。—人神之間擺哈龍門陣 2007年7月21日 (六) 15:58 (UTC)
一、其它語言沒有這個相關跨語言連結呢？二、就算有，先找到外文維基，再跑回中文，有效率嗎？三、重要的是，這個非中文重定向究竟妨礙著什麼了不能允許存在？四、你還是沒有給出沒有必要的理由，通過火車能到達目的地不能說明汽車沒有必要。— fdcn talk 2007年7月21日16:43 (UTC+8 7月22日00:43)
我可以說出一個現實的理由，大陸的很多人是沒有權限編輯英維的，但他可以創建中文維基的非中文重定向。即使不談這個理由，放著一個可以方便讀者定位的技術棄而不用，我想不出有什麼道理，這非中文重定向根本無關中文政策的。其它語言維基都能允許外文重定向獨中文維基不允許有些奇怪。其實現在所討論的東西，都在Wikipedia:投票/非中文重定向頁面第二次投票里已討論過了。— fdcn talk 2007年7月21日16:53 (UTC+8 7月22日00:53)

只要規定這些重定向不可使用於條目內文中，那我對這些重定向就沒有意見。例如，一個翻譯名稱有爭議的名詞，在其他條目中，仍然必須使用中文描述，可使用noteTA標籤，但絕對不能因為有爭議就去使用原文。--Jnlin（討論） 2007年7月21日 (六) 18:49 (UTC)

    • 我認錯，在討論前研究不足，在英文維基試過幾種語言（中文、法語、日文），在相關條目均有重定向，既然這樣的東西不違反方針，又能夠方便用戶，當然很好，故(＋)支持。其實從我原來說的很多東西應該能看出來我是很想讓維基對普通用戶更加方便的（而不是對老用戶，因為老用戶自己會有很多辦法）。並且建議相關內容形成方針，使得以後處理有個參照。—人神之間擺哈龍門陣 2007年7月21日 (六) 19:26 (UTC)
本節達成共識，請參與下方方案討論。

方案

討論至今，貌似已有共識。在此提出方案，看看大家認為如何？

  1. 允許條目主題之原文名稱重定向
    1. 例如：Alfred Adler重定向至阿爾弗雷德·阿德勒、New York University重定向至紐約大學
    2. 使用WP:名從主人原則。如果「原文名稱」包含數種語言，則那些語言都可以重定向。
  2. 允許有一定使用量的常用語種重定向
    1. 常用語種之判斷，第一種方式可參考各語種維基百科的用戶數量（暫時想不到其他方式）。
      • 根據2017年3月11日（六）00:00 (UTC)的數據，英語有30,420,626名用戶、西班牙語有4,535,276名用戶、法語有2,737,359名用戶、德語有2,599,852名用戶、漢語有2,350,767名用戶、俄語有2,065,026名用戶。
    2. 另一種方式，則是以聯合國官方語言為準，即：阿拉伯語、漢語、英語、法語、俄語、西班牙語。
    3. 另一種方式，則是允許使用人口數最多的十種語言（漢語、西班牙語、英語、阿拉伯語、印地語、葡萄牙語、孟加拉語、俄語、日語、德語）
    4. 或者是直接允許所有語言的重定向。
    5. 當然若有其他方案也歡迎提出。

以上。-和平、奮鬥、救地球！（留言）歡迎加入維基Telegram群 2017年3月11日 (六) 03:50 (UTC)

我記得以前是不鼓勵，不推薦，但也不反對。但大批量的創建這類重定向則會被視為惡意--百無一用是書生 (☎) 2017年3月13日 (一) 03:24 (UTC)
第1種（原文）比較合理（第二種好像給得太廣了？），但仍然希望能涵蓋到一些化學、數學、電子方面的英語重定向。——Artoria2e5編 保持討論完整，直接{{ping}}我回復。 2017年3月13日 (一) 03:29 (UTC)
@Artoria2e5：對非中文重定向的方針似乎已經提及了對學術專有名詞的允許。——꧁༺星耀晨曦༻꧂（留言） 2017年3月13日 (一) 10:08 (UTC)
其實第二項主要是英文生詞，比如berlin之類。我贊成設五大語言。--Temp3600（留言） 2017年3月17日 (五) 18:12 (UTC)
(－)反對，維基百科不是英漢詞典，不需要建立英文與中文的連接。另外，維基數據已經提供了英文與中文的連接，不需要在維基百科本地利用重定向再次手工實現。--Gqqnb（留言） 2017年3月26日 (日) 18:34 (UTC)
這個是方便性的問題了。就是看你覺得設berlin, cambridge, isaac asimov 之類的重定向好不好。--Temp3600（留言） 2017年3月26日 (日) 18:48 (UTC)

重定向問題

本主題或以下段落文字，移動自Wikipedia:互助客棧/條目探討。執行者：Jimmy-bot（留言） 2017年6月1日 (四) 16:42 (UTC)。

  • 對於書籍（ISBN）、化學品（CAS號）等條目，是否可以用ISBN、CAS等建立重定向？

例如，輸入「87-51-4」，重定向至吲哚-3-乙酸。這樣可以解決在不輸入中文的情況下方便檢索，或者化合物名稱太過複雜、輸入別名無對應重定向等問題。（註：這些內容完全可以通過bot完成）

--Leiem（留言） 2017年5月19日 (五) 09:12 (UTC)

問題是你怎麼知道某本書的ISBN？等你知道它的ISBN，通常你也知道它的書名了；反過來講，連書名都不知道，又怎會知道ISBN呢？還有ISBN要不要用"-"隔開，怎麼隔(幾位一節)，這也是問題。-游蛇脫殼/克勞棣 2017年5月19日 (五) 09:57 (UTC)
這樣子的話ISBN就不可行了。CAS呢？--Leiem（留言） 2017年5月19日 (五) 11:36 (UTC)
CAS應該可以的，我對化學很不熟悉。-游蛇脫殼/克勞棣 2017年5月19日 (五) 11:43 (UTC)
符合WP:重定向嗎？——路過圍觀的Sakamotosan 2017年5月19日 (五) 12:38 (UTC)
其實在下覺得意義不大，因為在搜索欄輸入CAS號的話，搜索結果裡面也是有的。--dqwyy（談笑風生）🌸環状線を走り抜けて🌸回復請ping我 2017年5月20日 (六) 07:06 (UTC)
有CAS重定向的話，應該能夠跨語言搜索了？--Leiem（留言） 2017年5月22日 (一) 09:18 (UTC)

有關英文名稱的重定向連結

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2017年8月13日 (日) 08:42 (UTC)。

本主題或以下段落文字，移動自WP:VPD。

有關英文名稱的重定向連結 (Part II)

建議加入允許建立非學術性的重定向以區別類似的中文詞彙，這樣可以減少連結翻譯器出錯的機率。=)

原因：

謝謝各位！=) --It's gonna be awesome!✎Talk♬ 2017年7月28日 (五) 10:07 (UTC)

應解釋為什麼不用GOOGLE，而要耗費維基人的時間心力去進行這項計劃。這些重定向有數十萬條，單以你一人之力不可能全部完工。其他人為什麼要幫你?--Temp3600（留言） 2017年7月31日 (一) 08:52 (UTC)
你好，因為Google中的定義各有不同，比如說有些網站可能會說暈眩跟眩暈是相同的，但在中文維基百科上面是不同的，因此有因地制宜的必要。另外，這個計劃沒有強迫他人做的意思喔，只是提議開放喔。=) --It's gonna be awesome!✎Talk♬ 2017年8月3日 (四) 01:09 (UTC)

提議：開放外語重定向

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2017年9月7日 (四) 16:42 (UTC)。

在下遇到許多連結翻譯器也無法翻譯的外語。但在下希望只手動重定向一次即可，故提此議案，希望一勞永逸。通過後即可比照英文維基百科，接納所有外語非惡意或破壞的重定向。= )

--It's gonna be awesome!✎Talk♬ 2017年8月12日 (六) 10:43 (UTC)

外語重定向爭議都好像已經有兩個月了，閣下覺得此提案會有一絲機會獲得通過？--J.Wong 2017年8月12日 (六) 11:05 (UTC)
只要有一絲機會，在下就會繼續努力，不會放棄！！ ✊✊ 謝謝您的問候！祝您有個美好的周末夜晚! ^_^ --It's gonna be awesome!✎Talk♬ 2017年8月12日 (六) 11:07 (UTC)
閣下提案至今都無法獲得通過，某程序上就是閣下未有顧及另一方想法。--J.Wong 2017年8月12日 (六) 11:31 (UTC)
>//< 抱歉。怎麼做才能讓在下能有顧及另一方想法呢？謝謝你--It's gonna be awesome!✎Talk♬ 2017年8月12日 (六) 11:41 (UTC)
我覺得在這個自由的世界真的滿難凝聚共識的，曾有一個美國人說 It's too diverse to reach out a consensus.來形容槍枝管制。我還滿好奇最初這些重定向規則是如何建立的。 無論如何，在下仍願意虛心受教。謝謝你--It's gonna be awesome!✎Talk♬ 2017年8月12日 (六) 11:45 (UTC)
閣下所說的「外語」重定向指的是除「漢語」以外所有或任何語言的重定向嗎？--NoobWayne™討論 2017年8月12日 (六) 12:23 (UTC)
這個嗎？我也不確定該如何精確的表達，但就跟英文版中的定義一樣en:Category:Redirects_from_alternative_languages =) --It's gonna be awesome!✎Talk♬ 2017年8月12日 (六) 13:06 (UTC)
外語的定義應該為英語、法語、德語、日語、韓語、......等語言。= ) --It's gonna be awesome!✎Talk♬ 2017年8月12日 (六) 13:10 (UTC)

(－)強烈反對，無建設性。--⌬胡蘿蔔 熱烈慶祝化學成為動員令主題 2017年8月12日 (六) 13:21 (UTC)

  • 各位維基百科人好，有鑑於時常在報章雜誌上看到許多老弱殘疾因為錯誤的資訊而導致延誤就醫等悲劇發生（今天台灣的蘋果日報就有好幾則），因此在下十分擔心維基百科中存有許多尚未被發現的錯誤重定向（在下是ADHD，本身常粗心、錯過細節，所以在下推測在下所發現的錯誤可能只是冰山一角），因此雖然在下提醒自己事緩則圓，但還是抵不過良心的壓力，畢竟能早一天發現並改正錯誤的重定向，或許就能多救幾個人，而開放外語重定向能加快此一進展。提供正確的資訊本來也就是維基百科的義務，許多搜尋引擎也都把維基百科的條目視為可靠資訊列為搜尋結果的頂端，因此維基百科肩負著巨大的社會責任，所以請容許在下衝動那麼一次，在此宣布即日起此條文公示七日。再次感謝社群的理解。謝謝你們--It's gonna be awesome!✎Talk♬ 2017年8月13日 (日) 05:16 (UTC)
  • (＊)提醒有任何想法也歡迎提出與閣下討論。=) --It's gonna be awesome!✎Talk♬ 2017年8月13日 (日) 05:16 (UTC)
如果你這樣衝動的話，那就有可能在試圖闡述觀點了，這樣有可能永遠不能再編輯了。——路過圍觀的Sakamotosan 2017年8月13日 (日) 13:08 (UTC)
實際上本來就沒有出現問題，你更多是圍繞連結翻譯器運作錯誤、用語便捷性等提出這是個問題。但是，連結翻譯器更像是設計上的失誤；用語的話本地是允許原語言專有術語作為外語重定向的例子。所以本身並不存在問題，也沒有需要解決的需求。——路過圍觀的Sakamotosan 2017年8月14日 (一) 05:42 (UTC)
您好，但有些中文條目會被對應到錯誤的英文維基百科條目，即便正確的英文維基百科條目是存在的。--It's gonna be awesome!✎Talk♬ 2017年8月15日 (二) 04:24 (UTC)
請舉出詳細例子，我用連結翻譯器那麼多次都沒遇過。--Zest 2017年8月17日 (四) 16:24 (UTC)
與其說是沒遇過不如說是沒發覺吧。在下從上到下以舉出好幾個例子了。=) --It's gonna be awesome!✎Talk♬ 2017年8月17日 (四) 17:12 (UTC)

提案：刪除重定向方針中「字典裡查得到」的規則

我認為百科辭典或百科全書中已有的名詞、名詞性詞組或短語應該可以作為重定向，字典和詞典中已有的的名詞、名詞性詞組或短語也可以作為重定向，但是需要慎重一點--百無一用是書生 (☎) 2017年8月17日 (四) 11:34 (UTC)
謝謝你 另外請教 @Shizhao：，若投反對票並未附上合理理據是否應採納呢？(例如：下方的Carrot君)。--It's gonna be awesome!✎Talk♬ 2017年8月17日 (四) 14:18 (UTC)
這邊是討論不是投票，沒有規定一定要給任何理由，無須任何理由，在此告知閣下，下次先發起討論，看討論有無需修改方針。--Zest 2017年8月17日 (四) 16:22 (UTC)
「下次先發起討論，看討論有無需修改方針。」請問這是什麼意思呢？~ --It's gonna be awesome!✎Talk♬ 2017年8月17日 (四) 17:15 (UTC)
最近一次投票是十年前的事，平心而論，十年前的討論及規定，可能可以再作討論及調整。只是對我而言，提議者的提出方式及回覆方式，很大程度影響了這個議題的討論方式及結果，如上面的
「只會講好聽話、漂亮話、滿口大道理的人，並不是每個都是這麼言行合一的。不好意思。」
「好吧~ 反正就交給歷史來判斷囉~ : ) 反正就是錯誤的重定向繼續錯誤下去，然後寄望那些講好聽話的人真的會去做些什麼來改善。」
這類回覆，我會覺得比較偏情緒性，也讓我不太會想參與這個議題的討論（結果雖說是不想參與討論，還是留了一堆的留言），我也不想回答「若這個不修正，要如何處理......的問題。」之類的問題。--Wolfch (留言) 歡迎參與今年的動員令 2017年8月17日 (四) 19:10 (UTC)
嗨~您提到的第一個留言，在下承認是受到蘭斯特哥的話語影響，顯得有情緒性，不好意思。至於第二個留言，在下只是刻意想凸顯反對者對人不對事的做法，而且在下自認對於避免給予錯誤資訊的議題上良心過得去，且短時間內無意再白費力氣行這類的公益性的 endeavours，所以也就沒再用隱晦的方式表達心聲，總之，很高興您看得出來。 Incidentally, 您也太早起了!--It's gonna be awesome!✎Talk♬ 2017年8月18日 (五) 14:10 (UTC)


所以我一直覺得我完全對得起自己的良心，不會因此失眠（歡迎不是為反對而反對的人參與協作XD），但願那些blind opposition supporters' 在意的人、深愛的人都能健健康康的（我承認這有點情緒性，但我真的對此應過未過的且明顯對人不對事的鬧脾氣結果深感惋惜）。「豈能盡如人意，但求無愧於心。」--It's gonna be awesome!✎Talk♬ 2017年8月20日 (日) 07:58 (UTC)

非中文重定向

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2017年12月16日 (六) 08:42 (UTC)。

緣起

  • 一個詞彙的意思很多，其實很難決定要選哪個，特別是新創翻譯自英文維基百科的條目時。因此創外語重定向，來確保讀者不會因為編者命名不精確而找不到想要的資料。
  • 一些專有名詞常常出現某個字典查得到，另個字典卻查不到的情形，甚至存在兩部字典之間的解釋不同的問題，然而編者無法一一查閱所有的字典。最終容易引起不必要的爭議。
  • 目前的辦法中並無指定字典是哪一部，以及是否可以將字詞分開查詢。若允許將字彙分開查詢則可能會把 Sinus rhythm ‎誤以為是鼻竇的律動。
  • sinus infection 可能是某個腔感染，並不專指鼻竇。 在sinus創立前，若於搜尋框搜尋 Sinus infection，鼻竇炎於在下印象中在搜索結果中名列前茅，具有誤導的問題。想必那位於Yahoo!知識問答提問的人應該是在到訪中文維基百科後仍充滿疑惑，才去雅虎知識提問。中文維基百科自詡為專業百科，應該盡量解決歧義的問題。—以上未簽名的留言由It's gonna be awesome（對話｜貢獻）於2017年11月25日 (六) 17:56 (UTC)加入。
  • 上方建立CAS號重定向提到「一些複雜的化學品可能有多個別名，尤其是含音譯字的名稱，增加了條目名的不確定性。」，在下十分認同，「尤其是含音譯字的名稱」，會「增加了條目名的不確定性」。—以上未簽名的留言由It's gonna be awesome（對話｜貢獻）於2017年11月25日 (六) 18:11 (UTC)加入。

解決辦法

  1. 刪除字典裡查不到的要求。
  2. 找出一本共同參考的字典。
    1. 但問題是，維基百科可以要求編者使用同一本字典，但無法要求讀者也使用同一本字典。
    2. 可能難以找出一本大家都認同的字典。

方案一：修訂Wikipedia:重定向#非中文重定向問題

現行條文

根據投票，維基人達成共識，同意建立下列數種非中文重定向頁：

  1. 學術名稱：科學用語、電腦技術等的專門用語、動植物的學名，這些詞語是字典裡查不到的，例：Homo sapiens→人。

（略）

提議條文

根據投票，維基人達成共識，同意建立下列數種非中文重定向頁：

  1. 學術名稱：科學用語、電腦技術等的專門用語、動植物的學名。

（略）

方案二：修訂Wikipedia:重定向#非中文重定向問題

現行條文

根據投票，維基人達成共識，同意建立下列數種非中文重定向頁：

  1. 學術名稱：科學用語、電腦技術等的專門用語、動植物的學名，這些詞語是字典裡查不到的，例：Homo sapiens→人。

（略）

提議條文

根據投票，維基人達成共識，同意建立下列數種非中文重定向頁：

  1. 學術名稱：科學用語、電腦技術等的專門用語、動植物的學名，這些詞語是(某部大家同意採用的)字典裡查不到的，例：Homo sapiens→人。

（略）

參考資料

--It's gonna be awesome!✎Talk♬ 2017年11月25日 (六) 17:55 (UTC)


  • 閣下能否解釋Sinus rhythm是什麼意思、鼻竇的律動的英文又是什麼又是指什麼意思， sinus infection的中文是什麼、鼻竇的英文又是什麼？先讓我們看看差異性。--米莉婭諾朵卡 2017年11月25日 (六) 19:30 (UTC)
    • 謝謝米莉婭諾朵卡的提問：
Sinus
非中文 中文 解釋
Sinus rhythm 竇性心律（英文：sinus rhythm） 是指當心肌的去極化始於竇房結時產生的心藏律動。[1]其特點是心電圖（ECG）中展示方向正確的P波。竇性心律是心臟的正常電信號活動的必要不充分前提。
Sinus Rhythm 鼻竇的律動 -
sinus infection 鼻竇/竇 感染 鼻竇炎 或 器官或組織的囊或腔室感染發炎
Paranasal sinuses / sinus 鼻竇 又名鼻旁竇，位於人的頭顱，在頭骨之間、鼻腔周圍的顱骨與臉骨之內。

--It's gonna be awesome!✎Talk♬ 2017年11月25日 (六) 19:53 (UTC)

討論區

瞭解， 謝謝你--It's gonna be awesome!✎Talk♬ 2017年11月28日 (二) 05:43 (UTC)

討論一

  • 鼻竇的律動是什麼，表示沒有這東西，除非讀者自己胡亂查詢解讀才會變成鼻竇的律動，怎麼不會查全稱查定義也會出現竇律這個名稱，竇這字為何一定是鼻竇？--米莉婭諾朵卡 2017年11月25日 (六) 20:05 (UTC)
    • (：)回應英文維基百科定義的，該字確實很容易混淆：
A sinus is a sac or cavity in any organ or tissue, or an abnormal cavity or passage caused by the destruction of tissue. In common usage, "sinus" usually refers to the paranasal sinuses, which are air cavities in the cranial bones, especially those near the nose and connecting to it. Most individuals have four paired cavities located in the cranial bone or skull. — en:Sinus (anatomy)
    • 如果是我遇到這種情況，困惑之餘應該也會去Yahoo! 問問看。

--It's gonna be awesome!✎Talk♬ 2017年11月25日 (六) 20:10 (UTC)

討論二

      • Google「鼻竇 英文」得出來的結果當然是sinus，但是一般人如果遇到看不懂的英文單詞sinus，應該會去查「sinus 中文」，這樣得出來的結果就是「竇」了，你上面提到的容易混淆的這一段可以寫在竇 (生物構造)中，再加入英文維基百科en:Sinus (anatomy)中列舉的「人體內的竇」就能夠解決這個問題。
如果用戶遇到Sinus rhythm不認識，直接搜索「Sinus rhythm」，搜索結果就是竇性心律。在慣用中文的Google界面中，搜索結果右側也會直接顯示竇性心律的維基百科連結，也很方便。
關於Yahoo!上的這個問題，英國NHS、美國CDC等機構都認為sinis infection通常是指的就是鼻竇炎sinusitis，這裡還有一句"The terms "sinus infection" and "sinusitis" are often used interchangeably"，英文維基百科也是將sinus infection重定向至sinusitis，因此搜索Sinus infection出現鼻竇炎應該是沒有什麼問題的…… --#young[誰？] 2017年11月26日 (日) 06:58 (UTC)
        • 感謝您的意見。
以下為在下給您的說明：
  1. 一般會來中文維基百科查詢甚至前去Yahoo!知識詢問相關問題的人，其英文能力應該還不到能分辨何時該兩個單字一起查或是分開查詢 (例如我自己)。如果我發現分開查與一起查所得到的結果不同，我會心生困惑。此時維基百科存在的目的之一就是協助讀者消去歧義。
  2. 我常用的劍橋大學字典會出現鼻竇，竇兩個解釋。
  3. 另外對於一個台灣人來說，如果去醫院的網站查相關資訊會發現網站並無附註 Sinus infection ，也容易心生困惑。多數會來中文維基百科及Yahool!詢問的人，或許我們必須考量其外語能力是否如閣下一樣卓越。

再次感謝您撥冗提出您寶貴的意見，敬祝編安 ^_^ --It's gonna be awesome!✎Talk♬ 2017年11月28日 (二) 04:50 (UTC)

討論三

CAS號是一個統一的號碼，一種化學品只會有一個。閣下能否保證生物學名只會有一個?--Temp3600（留言） 2017年11月26日 (日) 08:41 (UTC)
您好，感謝您提出您寶貴的意見，以下為在下給予您的答覆：
基本上是的，此類重訂向最重要的目的在於協助讀者消歧義 (例如：癲癇、癲癇發作、肌肉顫搐、抽搐、痙攣、抽動綜合症、顫抖、抖動等) ，在下估計多數的情況下僅會出現頂多一到兩個重定向。
感謝您的參與，敬祝生活愉快！ ^_^--It's gonna be awesome!✎Talk♬ 2017年11月28日 (二) 05:09 (UTC)

討論四

  • 不太理解該提案的想法。個人理解，外語重定向適用於明顯常用而需要在搜索時被重定向的情況，作為搜索索引被建議和列出不是它的本職工作。維基數據已有別名功能，應該去建議搜尋引擎組件考慮這些數據。
  • 將單詞分開查不應該納入考慮。多個常用名稱可以在序言、章節或信息框中撰寫，在搜索結果中找到，匹配能力也是搜尋引擎的問題。
  • 現行條文中的「字典里查不到」限於學術、專業用語，指創建普通（日常）字典中不收錄但在學術界常用的詞語，這個字典不限於某幾本，而是一個範圍、常識，比如大多數已收錄/未收錄。對於這種詞語重定向的使用需求，個人不了解，不作評論。--YFdyh000（留言） 2017年11月26日 (日) 22:45 (UTC)
    • 您好，很開心能在此回覆您提出的寶貴見解：
在下之前曾發現， 在搜尋框搜尋 Malignant tumor ，其正確的搜尋結果排在第十三順位，也就是說讀者必須拜訪搜尋結果的第二頁才會找到正確的條目。若以這邊舉的 sinus infection 為例子，搜尋結果會出現 鼻炎、鼻竇炎、鼻咽癌、空鼻症候群、心肌炎等建議。這邊也會出現歧義的問題。

再次感謝您的參與，敬祝身體健康，萬事如意！ ^_^ --It's gonna be awesome!✎Talk♬ 2017年11月28日 (二) 05:35 (UTC)

  • 感覺這類非專有名詞重定向，更像是貼英語翻譯的方便，直接複製en代碼後就省事了，因為英文連結用重定向代替，而沒有考慮直接翻譯為對應的中文，在中文區的英文更多應該作為其中文名字的輔佐解釋（例如標示命名的外語名稱、或者中文命名翻譯不能準確時的附註），不是主導地位，也不應該以自己的豐富英文思維去考慮讀者或者其他編者會理解英文。癌症infobox的英文明顯有喧賓奪主的感覺。——路過圍觀的Sakamotosan 2017年11月28日 (二) 07:38 (UTC)
(：)回應 非常感謝您的提醒： 癌症infobox 的內容已經更新！ 未來重定向會以專有名詞為主。--It's gonna be awesome!✎Talk♬ 2017年11月28日 (二) 07:50 (UTC)

考量七日除酌修的建言外無反對意見，即起公示七日。謝謝。--It's gonna be awesome!✎Talk♬ 2017年12月3日 (日) 23:08 (UTC)

結果是要哪個方案？--Xiplus←A2093064 2017年12月3日 (日) 23:44 (UTC)
方案一。因為方案二很難找到共同規範的字典。--It's gonna be awesome!✎Talk♬ 2017年12月4日 (一) 00:15 (UTC)
(？)疑問：未見達成共識。不太理解方案要做的是什麼，方案一是擴大收錄範圍、方案二是明確收錄範圍？--YFdyh000（留言） 2017年12月3日 (日) 23:51 (UTC)
您好，目前是以方案一為主，最主要的目的在於消歧義。--It's gonna be awesome!✎Talk♬ 2017年12月4日 (一) 00:15 (UTC)
目前沒看到明確的共識，也沒看到許多人認為必要修改，此時寫「考量七日除酌修的建言外無反對意見，即起公示七日。謝謝。」好像意義不大--Wolfch (留言) 2017年12月4日 (一) 05:11 (UTC)
您好，在下只是參照之前在此處提的修法流程進行。若閣下有任何建議也歡迎提出。謝謝。--It's gonna be awesome!✎Talk♬ 2017年12月4日 (一) 13:06 (UTC)
之前有些討論（例如Wikipedia_talk:回退功能）已有多人明確的支持該作法，因此可以用「即起公示七日」，和此提議的討論情形不同。--Wolfch (留言) 2017年12月4日 (一) 20:17 (UTC)
我是參考上方的"修改翻譯指引"。--It's gonna be awesome!✎Talk♬ 2017年12月5日 (二) 04:43 (UTC)
看完了二個方案, 認為不太需要修改這兩案都不贊成--Wolfch (留言) 2017年12月5日 (二) 08:25 (UTC)
謝謝您提出您的個人意見，若您認為有更好的方式能避免爭議，也歡迎您分享。謝謝。--It's gonna be awesome!✎Talk♬ 2017年12月5日 (二) 09:05 (UTC)
@Wolfch：您好，想請教為何在下感謝您提出意見後，您反而更直接的反對呢？--It's gonna be awesome!✎Talk♬ 2017年12月6日 (三) 02:56 (UTC)
之前回覆的「不太需要修改」其實是指「不需修改原來的重定向規則」，不過我沒說明清楚，容易誤解為「提案不太需要修改」，因此改為直接表達對這兩個提案的立場--Wolfch (留言) 2017年12月6日 (三) 04:47 (UTC)
瞭解， 謝謝你--It's gonna be awesome!✎Talk♬ 2017年12月6日 (三) 05:36 (UTC)

我覺得大家可能未能了解此修改所影響的範圍，不然請提案者舉例一些您曾經建立但被刪除的重定向，經此提案修訂後能夠建立的有什麼（可以從存廢討論4/30、5/18、5/19挑選）。--Xiplus←A2093064 2017年12月4日 (一) 13:47 (UTC)

好的，稍後有空時就會提出，感謝！--It's gonna be awesome!✎Talk♬ 2017年12月5日 (二) 04:43 (UTC)
比如說：鼻涕 (mucus) 與 膿鼻涕 (Phlegm) 就有本質上的不同，但從中文翻譯看起來，會以為膿鼻涕是鼻涕的進階版。
比如說：腹痛、喪失胃口、反胃、減肥以及體重降低中文字面看起來意思好像很類似，但其實他們打從定義就已經不同了。
幻覺、妄想、抽蓄、抽搐、癲癇、驚厥、昏厥、昏迷、頭暈、眩暈、小頭暈（英語：dazzling）、and 昏昏欲墜（英語：syncope） 各自都有不同的定義與翻譯，因此在下認為有必要允許創立學術名稱重定向來消歧異，這也符合一個自許為專業百科的宗旨。--It's gonna be awesome!✎Talk♬ 2017年12月5日 (二) 06:08 (UTC)
閣下尚未答覆Xiplus君的提問，請羅列。單看閣下的兩個提案，首先反對提案二，提案一也沒有足夠讓我信服的理由。--米莉婭諾朵卡 2017年12月5日 (二) 09:48 (UTC)
(：)回應嗨，比如說：Dose, dosage, paranoia, delusion, stroke, heart stroke, asthma stroke, cerebrovascular incidence, cerebrovascular event, physiological tolerance, tolerance, drug tolerance, anxiety disorder, generalized anxiety disorder, plasma proteins, blood proteins. --It's gonna be awesome!✎Talk♬ 2017年12月6日 (三) 03:09 (UTC)
您的提案似乎是給所有學術名稱建立重定向，但這樣的重定向使用率未曾可知，也難以全面維護。WP:NOTJARGON。維基百科沒有過「自許為專業百科」，而是相反。已理解您的提案，建議行文就學術名稱、常用度、中文名詞易混淆等方面限定。--YFdyh000（留言） 2017年12月5日 (二) 11:10 (UTC)
您好，謝謝您寶貴的建議。目前是希望能建立一到兩個最常用的學名，用以消除ambiguation. 在下認為最有效率的方式即為刪除現有的字典規定，畢竟該規定在其他情境下也都容易造成爭議。至於專業百科的理解是因為許多專題的評級都提到GA、FA、甲級條目需要符合 專業、傑出、深入；是可靠的百科資訊來源。這個規範。--It's gonna be awesome!✎Talk♬ 2017年12月6日 (三) 03:09 (UTC)

建立CAS號重定向

本主題或以下段落文字，存檔自Wikipedia:VPP。執行人：——Aotfs2013 留於 2017年12月27日 (三) 11:38 (UTC)。

本討論已經結束。請不要對這個存檔做任何編輯。

建議在WP:重定向中「非中文重定向問題」增加：「CAS號：化學品的唯一標識，如106-98-9 → 1-丁烯」。

一些複雜的化學品可能有多個別名，尤其是含音譯字的名稱，增加了條目名的不確定性。 --Leiem（留言） 2017年11月12日 (日) 17:07 (UTC)

未見不可。Bluedeck 2017年11月13日 (一) 07:29 (UTC)
同意。--Temp3600（留言） 2017年11月13日 (一) 15:10 (UTC)
wikidata中有CAS號，在搜索框中輸入CAS號能得到結果。維基百科的話加引號精確匹配也能搜索到，不加倒確實找不到。 Abacn（留言） 2017年11月14日 (二) 01:08 (UTC)

但是CAS號是沒有規律的編號，只能從其他地方找到，使用SMILES或InChI如何，有規則可以算，可以推出分子解構，搜尋程度也好找相似物質，各有優缺，歡迎列舉意見。--米莉婭諾朵卡（留言） 2017年11月14日 (二) 02:39 (UTC)

1-丁烯那個，CAS不加引號確實搜不到。CAS是數字和短橫構成的，方便輸入，個人感覺比SMILES和InChI簡單一點。另外，SMILES里井號等符號會不會出現技術問題？--Leiem（留言） 2017年11月14日 (二) 13:06 (UTC)
PubChem和ChemSpider也是數字，但需要考慮到會和其它條目在名稱上重複。--Leiem（留言） 2017年11月17日 (五) 11:33 (UTC)
@蘭斯特：SMILES或InChI不可能成為頁面標題，因為含有MediaWiki的保留字元（[、;主要用於解析頁面名稱、連結），若強制建立出來的話，將會導致整個系統出現無法預期的後果，比如解析錯誤錯誤、崩潰。比如氫氧化鈉O[Na]、1/Na.H2O/h;1H2/q 1;/p-1。--　宇帆（留言·歡迎簽到·聯絡） 2017年11月26日 (日) 08:55 (UTC)
(＋)支持--It's gonna be awesome!✎Talk♬ 2017年11月25日 (六) 17:49 (UTC)
(＋)支持：CAS有唯一性，且不會出現MediaWiki的非法字元或保留字元（[、;等），因此沒有問題。--　宇帆（留言·歡迎簽到·聯絡） 2017年11月26日 (日) 08:55 (UTC)
(＋)支持，good idea。可以使檢索變得更容易。-- FV4101 Charioteer·基本法 2017年12月16日 (六) 12:01 (UTC)

(＋)支持：CAS號有唯一性--Richard923888 ~\(≧▽≦)/~ 和我聊天 2017年12月17日 (日) 06:03 (UTC)

修訂如下：

現行條文

==非中文重定向问题==
... （略）
7. 時區：世界各地的時間UTC+8、GMT+8等等。

提議條文

==非中文重定向问题==
... （略）
7. 時區：世界各地的時間UTC+8、GMT+8等等。
8. 化學品CAS號：文獻中所記載的每種化合物的唯一編碼，如106-98-9→1-丁烯。

以目前討論的情況來看以CAS號作重定向無異議，可以開始公示。有其它建議歡迎補充。--Leiem（留言） 2017年11月17日 (五) 11:33 (UTC)

這個能夠確定CAS號的編碼只此一家，完全唯一，不會有其它的編號與它重複？--百無一用是書生 (☎) 2017年11月20日 (一) 02:12 (UTC)
目前沒發現其它地方的編號與之重複的。--Leiem（留言） 2017年11月20日 (一) 14:31 (UTC)
翻閱上列討論，未見異議，現公示七日，如無異議，即告通過。--J.Wong 2017年12月6日 (三) 23:35 (UTC)
(－)反對，基於以下幾點：
  1. 並沒有在其他維基百科建立的先例，除了大量用機器人建立化學條目的某幾個維基，像德語即使大量用機器人建立化學條目大部分也沒有重定向；
  2. 可能有其他極少數「數字串」會有其他含義；
  3. 不少物質都有對應多個CAS（比如鹽類、水合物），這些是否建立？嚴格來講他們對應的並不是同個物質。
以上。如有其他問題還會繼續提出。--CHEM.is.TRY 2017年12月10日 (日) 06:56 (UTC)
(：)回應「不少物質都有對應多個CAS（比如鹽類、水合物）」，應該說，某鹽類有關注度，所以某鹽類有條目，但某鹽類的水合物沒有關注度，所以會合併在某鹽類條目中，造成某鹽類、和某鹽類的水合物有不同的CAS號，這應該是「關注度不足重定向」，而非「某鹽類有多個CAS號」。--　宇帆（留言·歡迎簽到·聯絡） 2017年12月10日 (日) 07:38 (UTC)
首先你沒看懂我在說什麼，我指的鹽類是長春花鹼——硫酸長春鹼這種關係，後者是前者的鹽類。第二，重定向並沒有「關注度」的概念。第三很多物質及其鹽類/水合物都有關注度，比如前面的長春鹼、氯苯那敏、硫酸銅等等。--CHEM.is.TRY 2017年12月10日 (日) 08:54 (UTC)
(：)回應，水合物的CAS可以重定向至無水物，一些無水物的chembox里也會有水合物的信息。至於有機物成鹽的情況，硫酸鹽重定向至硫酸鹽，有機物母體重定向至母體。當鹽類（非CAS）重定向至母體（非CAS）時，CAS這樣做也沒什麼關係。至於數字串的問題，目前還沒看到有重複的。--Leiem（留言） 2017年12月10日 (日) 13:21 (UTC)
例如，7758-98-7（硫酸銅）和7758-99-8（五水合硫酸銅）都可以重定向至硫酸銅。--Leiem（留言） 2017年12月10日 (日) 13:26 (UTC)
ChemIStry君，尚有否其他意見？--J.Wong 2017年12月14日 (四) 10:30 (UTC)
我的第一個問題並未有人回答。--CHEM.is.TRY 2017年12月17日 (日) 09:51 (UTC)
對於第一個問題「沒有先例」，回答如下：
（1）參見Wikipedia:是英文維基說的！，每個維基百科有各自的特點。如果CAS號沒有其它維基百科重定向的先例，那麼中文維基百科可以成為先例。（PS:我曾在英文維基百科提過，但是沒人回應）；
（2）中文維基百科比英文維基百科創建CAS重定向條目更有需求性。化合物，尤其是有機化合物的命名，中文和英文有差別，如取代基（官能團）的位置，會影響在命名中的順序，有些時候一個物質在從英文翻譯成中文時，會直譯，或者讀者在查一個物質時，會根據其直譯結果來查，對於複雜的有機化合物，將名稱轉化為符合中文命名法的時候會有些麻煩。（例子：2-氨基-5-溴-4-溴甲基嘧啶 vs. 4-溴甲基-2-氨基-5-溴嘧啶）
（3）CAS號可以統一兩岸不同用字，可以在不方便輸入某些字符（如缺字）的時候檢索到條目。（關於兩岸用字討論的示例，參見Talk:𨥙；關於技術問題產生的標題簡繁混用，參見Talk:二噁英）
以上。目前想到這麼多。--Leiem（留言） 2017年12月17日 (日) 16:19 (UTC)
看了下Leiem的解釋，決定撤銷反對。到時如果通過是否需要機器人建立？如果機器人建立的話會不會又出現我提到的第三點問題（因為機器人並不能分辨出同一種物質，如果重定向尚未建立的話）。還有樓下烏拉不記得簽名加時間了 囧rz……。另@Wong128hk：--CHEM.is.TRY 2017年12月18日 (一) 12:15 (UTC)
感謝參與討論。有機器人會方便很多，機器人可以直接識別chembox模板框內的CAS一欄的信息。--Leiem（留言） 2017年12月18日 (一) 16:05 (UTC)
(！)意見，如要機器人建立請先處理Category:CAS不正確標誌的條目。--米莉婭諾朵卡 2017年12月19日 (二) 00:51 (UTC)
用關鍵詞把合併重定向的條目先找出來就可以了。「*.水合」、「[鹽酸|硫酸|硝酸|枸櫞酸]*.」類似這些。烏拉跨氪 2017年12月18日 (一) 16:18 (UTC)
(＋)支持，沒覺得有什麼不可以的啊。烏拉跨氪
如此，既無異議，提案通過，已經修訂。--J.Wong 2017年12月19日 (二) 14:03 (UTC)

關於遊戲條目英文原名是否應當重定向的問題

本主題或以下段落文字，存檔自Wikipedia:VPP。執行人：——Aotfs2013 留於 2018年1月2日 (二) 20:04 (UTC)。

在Telegram探討這個問題的時候，安亭同學曾經提出，一般不對英文名做到中文的重定向。但是遊戲條目有自己的特殊性，很多情況下，談中文名港台與大陸人之間並不知道說的是同一個遊戲，但是英文名是唯一的，例如使命召喚與決勝時刻，不知情的人可能以為他們談論的是兩部遊戲，但實際上一說英文名Call of Duty無論身在港台還是大陸都能理解。除此以外，還有英文名比中文翻譯名稱流傳更廣的情況，例如GTAV（俠盜獵車手）。因此我們是否可以考慮建立一個Bot，從Wikidata上面拉取數據然後建立遊戲英文名到中文名的重定向？喊這個醫學僧學習去！！！(User:March happy)（留言） 2017年12月22日 (五) 13:00 (UTC)

  • (－)反對 用bot建重定向，
  • 並不是所有的遊戲都存在命名不統一，更何況某些還有官方譯名；
  • 冷門遊戲重定向建了也白建；
  • 使用google搜索英文名即可自動跳轉到對應wiki條目；
當然對於手工建重定向我是沒有任何意見的。--Yangfl（留言） 2017年12月22日 (五) 13:15 (UTC)
(！)意見只要處理有不同譯名的遊戲，手動來就可以了，不過我認為就是冷門遊戲才該建，畢竟熱門遊戲很好找到各種資料，有些早期的遊戲也常不按原文翻，找起來不容易。 -KRF（留言） 2017年12月22日 (五) 13:37 (UTC)
(！)意見BOT建的話，閣下需要交一份更改列表給BRFA才行，不然萬一失控，後續維護非常麻煩。--Temp3600（留言） 2017年12月22日 (五) 14:48 (UTC)
提供另一個思路：WP:VG/GL#EN明確指出，外文遊戲應當標記產地語言原文和英文版名。我認為凡是在正文中提到的名稱，只要無害原則上都可以建重定向。（香蕉條目不會提到banana，但外文遊戲有英文版的，按指引都應當列出英文名的）
冷門遊戲方面我同意KRF君，有些遊戲中文圈都找不到多少資料，命名常規又鼓勵使用中文，有時編者會自己起一個中文名，別人不用原文還真難搜到呢。
另外要真要跑重定向的話，我倒更希望建議檢查一下各地轉換標題有沒有被重定向。抓wikidata的話，有些日文遊戲沒有美版，上面的英文可能是日文羅馬字。本地指引要求遊戲條目不標羅馬字，這種重定向建了可能有人反對。--Muhebbet（留言） 2017年12月23日 (六) 18:18 (UTC)

建立CAS號重定向後續討論

本主題或以下段落文字，移動自WP:VPP。執行者：--J.Wong 2018年1月22日 (一) 05:27 (UTC)。

前期工作

完成：已成立追蹤分類Category:CAS號重定向（搭配模板{{CAS號重定向}} （編輯 討論 說明  資訊 鏈入 歷史））--　宇帆（明年二月加入維基將滿十周年！留言·歡迎簽到·聯絡） 2017年12月19日 (二) 15:47 (UTC)
完成，先前已完成Category:CAS不正確標誌的條目的校對。（PS:已提出機器人請求：Wikipedia:機器人/作業請求）--Leiem（留言） 2017年12月19日 (二) 15:55 (UTC)

(：)回應分類Category:無CAS號重定向的物質條目應該可以協助機器人運作。--　宇帆（明年二月加入維基將滿十周年！留言·歡迎簽到·聯絡） 2017年12月20日 (三) 06:39 (UTC)
(～)補充：@Wong128hk、Leiem、乌拉跨氪、蘭斯特：已根據CAS號#格式寫了一個簡易的校驗函式
例如：
{{#invoke:Chemicals|check_CAS_test|1=7732-18-5}} → true （水）
{{#invoke:Chemicals|check_CAS_test|1=773332-18-5}} → false
{{#invoke:Chemicals|check_CAS_test|1=77-32-1-8-5}} → false
{{#invoke:Chemicals|check_CAS_test|1=娜娜奇}} → false[開玩笑的]
{{#invoke:Chemicals|check_CAS_test|1=abc-de-f}} → false
{{#invoke:Chemicals|check_CAS_test|1=124-38-9}} → true （二氧化碳）
{{#invoke:Chemicals|check_CAS_test|1=125-38-9}} → false
已運用於{{CAS號重定向}} （編輯 討論 說明  資訊 鏈入 歷史），會在建立錯誤的CAS號重定向時將其加入Category:CAS號不正確的重定向。請協助複查
--　宇帆（明年二月加入維基將滿十周年！留言·歡迎簽到·聯絡） 2017年12月19日 (二) 17:39 (UTC)
(～)補充：由於違反CAS號#格式的重定向一定符合WP:CSD#R3，因此這筆編輯Special:Diff/47445017直接將校驗失敗者掛上{{Delete}} （編輯 討論 說明  資訊 鏈入 歷史），@Wong128hk：若有違規請回退這筆編輯Special:Diff/47445017。--　宇帆（明年二月加入維基將滿十周年！留言·歡迎簽到·聯絡） 2017年12月19日 (二) 17:42 (UTC)

關於Module:Chemicals裡面校驗副程式，是否有用到d:Property:P231（用於加入CAS號的屬性）的屬性約束的格式約束，因為d:Property:P231的屬性約束的格式約束的正規表達式的格式化字串限定符是「[1-9]\d+-\d\d-\d」，見d:Wikidata:Database reports/Constraint_violations/P231#Format的檢測報告--林勇智 2017年12月21日 (四) 12:59 (UTC)

@D2513850：不需使用正規表達式，只需要檢查是否為三端由「-」分割組成的數字，以及最後一位校驗碼是否正確，此程式碼的正確性將會高於正規表達式：「因為正規表達式不能做加法乘法與取模核對校驗碼」。--　宇帆（明年二月加入維基將滿十周年！留言·歡迎簽到·聯絡） 2017年12月21日 (四) 13:04 (UTC)
@D2513850：(？)異議一個CAS編號以連字符「-」分為三部分，第一部分有2到7位數字，第二部分有2位數字，第三部分有1位數字作為校驗碼。CAS編號以升序排列且沒有任何內在含義。校驗碼的計算方法如下：CAS順序號（第一、二部分數字）的最後一位乘以1，最後第二位乘以2，依此類推，然後再把所有的乘積相加，再把和除以10，其餘數就是第三部分的校驗碼。舉例來說，水（H2O）的CAS編號前兩部分是7732-18，則其校驗碼= ( 8×1 + 1×2 + 2×3 + 3×4 + 7×5 + 7×6 ) mod 10 = 105 mod 10 = 5（mod是求餘運算符）--　宇帆（明年二月加入維基將滿十周年！留言·歡迎簽到·聯絡） 2017年12月21日 (四) 13:08 (UTC)
@D2513850：(？)異議
  1. 演算法先檢查是否由「-」分割，且為三部分，因此等價於「[1-9]\d+-\d\d-\d」
  2. 接著檢查是否每一位都是數字因此等價於「[1-9]\d+-\d\d-\d」
  3. 「此部分為該正規表達式的缺陷！！正規表達式並未檢查校驗碼！！」，接著依照CAS順序號（第一、二部分數字）的最後一位乘以1，最後第二位乘以2，依此類推，然後再把所有的乘積相加，再把和除以10，其餘數就與第三部分的校驗碼比對。
--　宇帆（明年二月加入維基將滿十周年！留言·歡迎簽到·聯絡） 2017年12月21日 (四) 13:19 (UTC)
@a2569875：根據CAS號#格式的敘述，d:Property:P231裡面正規表達式的格式化字串的值有錯，應該是[1-9]\d{1,6}-\d\d-\d，另外先做字串格式檢測，若該字串能匹配[1-9]\d{1,6}-\d\d-\d這個正規表達式才做校驗碼檢測。--林勇智 2017年12月21日 (四) 13:54 (UTC)
@D2513850：(？)異議多此一舉，只要確定其為由「-」分割的三串數字就夠了。--　宇帆（明年二月加入維基將滿十周年！留言·歡迎簽到·聯絡） 2017年12月21日 (四) 14:02 (UTC)
@a2569875：只要求Module:Chemicals裡面校驗副程式能正確運作就好了--林勇智 2017年12月21日 (四) 14:15 (UTC)
(：)回應@D2513850：pseudocode給你，這一定會運作好嗎
 虛擬碼 檢查CAS ( 參數 CAS號 : 字串) ->（英語：Return_statement） 布林字串
      如果 (以「-」分割 CAS號 字串的分割結果)的數量 ≠ 3
         回傳 「否（英語：False_(logic)）」
      宣告 CAS無分割號 : 字串 = 第1個分割區 與 第2個分割區 的字串合併結果
      如果 ( (第1個分割區字數 < 2) 或者 (第1個分割區字數 > 7) )
         回傳 「否（英語：False_(logic)）」
      如果  第2個分割區字數 ≠ 2
         回傳 「否（英語：False_(logic)）」
      如果  第3個分割區字數 ≠ 1
         回傳 「否（英語：False_(logic)）」
      宣告 檢查碼 : 整數 = (第3個分割區)轉成整數
      如果 ((第3個分割區)轉成整數 ) 失敗)
         回傳 「否（英語：False_(logic)）」
       
      宣告 檢查總和 : 整數 = 0
      迴圈 足標 i = 從 1 到 CAS無分割號的長度
         宣告 index : 自然數 = CAS無分割號的長度 + 1 - i
         宣告 cas_symbol : 整數 = (CAS無分割號的第index個字)轉成整數
         如果 ((CAS無分割號的第index個字)轉成整數 ) 成功)
             檢查總和 = 檢查總和 + (cas_symbol × i)
         否則 
             回傳 「否（英語：False_(logic)）」
      如果  (檢查總和 除以 10 的餘數) = 檢查碼
         回傳 「是」
      否則 
         回傳 「否（英語：False_(logic)）」
--　宇帆（明年二月加入維基將滿十周年！留言·歡迎簽到·聯絡） 2017年12月21日 (四) 14:44 (UTC)
(：)回應@D2513850：正規表達式根本不可能會具備求和、取餘數並比較校驗碼的能力好嗎，正規表達式非萬能，因為他不是程式語言，只是描述語言。--　宇帆（明年二月加入維基將滿十周年！留言·歡迎簽到·聯絡） 2017年12月21日 (四) 14:46 (UTC)
(：)回應@a2569875：若虛擬碼的如果((第3個分割區)轉成整數)失敗)改成如果(((第3個分割區)轉成整數)失敗)或((CAS無分割號)轉成整數)失敗))的話--林勇智 2017年12月21日 (四) 15:03 (UTC)
(：)回應@D2513850：那邊的用途是為了確保「檢查碼」不是Null--　宇帆（明年二月加入維基將滿十周年！留言·歡迎簽到·聯絡） 2017年12月21日 (四) 15:05 (UTC)
(：)回應@D2513850：比如上面故意放娜娜奇去測試，若執行「a = tonumber(娜娜奇)」（一定出錯，因為娜娜奇並不是一個數字），a會是Null，這時若直接把a拿去運算會Crash或Error，因此就讓他直接返回（英語：Return_statement）「否（英語：False_(logic)）」以避免出錯--　宇帆（明年二月加入維基將滿十周年！留言·歡迎簽到·聯絡） 2017年12月21日 (四) 15:11 (UTC)
宇帆先停停。另請@WhitePhosphorus：來看看代碼是否可行。--Temp3600（留言） 2017年12月21日 (四) 15:16 (UTC)
(：)回應@Temp3600：不認為我的演算法有甚麼問題，完全按照CAS號#格式來Implement。--　宇帆（明年二月加入維基將滿十周年！留言·歡迎簽到·聯絡） 2017年12月21日 (四) 15:22 (UTC)
(：)回應@Temp3600：比方說氯酸鈣在這個版本Special:固定連結/44678491，我的程式就有算出其檢查碼應為0 （手算 4×1 + 7×2 + 7×3 + 1×4 + 0×5 + 0×6 + 1×7 = 50, 50 ≡ 0 mod 10），可是條目中卻寫三，我的程式有順利抓出此錯誤，並加入Category:CAS不正確標誌的條目；三苯基膦氯化亞金的版本Special:固定連結/41034670中，也有檢查出含非法字元，我的程式有順利抓處此錯誤，並加入Category:CAS不正確標誌的條目。--　宇帆（明年二月加入維基將滿十周年！留言·歡迎簽到·聯絡） 2017年12月21日 (四) 15:37 (UTC)
我不會coding，所以我只能等WhitePhosphorus來判斷。--Temp3600（留言） 2017年12月21日 (四) 19:40 (UTC)
(：)回應@Temp3600：我只是覺得感覺現在好像「我講的一切都是錯的」，然後「白磷講的一切都一定是對的」，讓我覺得很難過。拜託不要這樣好嗎，我希望我們還能和平交流--　宇帆（明年二月加入維基將滿十周年！留言·歡迎簽到·聯絡） 2017年12月21日 (四) 20:41 (UTC)
@A2569875、Temp3600：沒什麼問題。只不過輸入字符串前後加任意個「-」函數看不出來，例如{{#invoke:Chemicals|check_CAS_test|1=-------2147485-70-7--------}} → false。不過看起來也不是什麼大問題。 --碸中嘌呤的白磷萃取 打譜 2017年12月23日 (六) 03:39 (UTC)

@a2569875：檢查CAS(娜娜奇娜娜奇娜-娜奇-1)的結果應該為「假」--林勇智 2017年12月21日 (四) 15:20 (UTC)

(：)回應@D2513850：{{#invoke:Chemicals|check_CAS_test|1=娜娜奇娜娜奇娜-娜奇-1}} → false。--　宇帆（明年二月加入維基將滿十周年！留言·歡迎簽到·聯絡） 2017年12月21日 (四) 15:23 (UTC)
(：)回應@D2513850：結果為假。不認為這裡會出甚麼錯。實際上也沒有出錯。--　宇帆（明年二月加入維基將滿十周年！留言·歡迎簽到·聯絡） 2017年12月21日 (四) 15:49 (UTC)
(：)回應@D2513850：還有，娜娜奇本來就不是一個數字（如果娜娜奇是一個數字，告訴我數學上等於多少 = ），所以在第一次迴圈 宣告 cas_symbol : 整數 = (CAS無分割號的第index個字)轉成整數之後的 如果 ((CAS無分割號的第index個字)轉成整數 ) 成功)這邊就會直接因為轉換失敗而返回（英語：Return_statement）「否（英語：False_(logic)）」，不會進到最後的取餘比對檢查碼程序。--　宇帆（明年二月加入維基將滿十周年！留言·歡迎簽到·聯絡） 2017年12月22日 (五) 15:27 (UTC)
目前看來代碼大致沒問題，CAS號的規則應該不會有特例(這句需要專業的解惑)，另外@D2513850：維基數據裡面的CAS有機器人添加嗎？如果是人手添加我會有擔心手誤的時候，如果有機器人依資料庫添加那較可放心，另@A2569875：如果條目沒有輸入CAS碼，而維基數據有可以在條目添加維基數據存在而條目內沒有提供CAS碼，在依人手或機器人添加（這兩個任務是區分的）。--米莉婭諾朵卡 2017年12月22日 (五) 15:14 (UTC)

刪除所有的純繁簡重定向

本主題或以下段落文字，移動自Wikipedia:互助客棧/其他。執行者：Jimmy-bot（留言） 2018年3月19日 (一) 08:42 (UTC)。

提議刪除純粹的繁簡重定向，如哈薩克 => 哈萨克。這種重定向大多是早期（>10年前）MediaWiki尚不支持標題自動轉換的遺留產物，如今MediaWiki已支持自動轉換，無須建立重定向。經測試，刪除不會對現有頁面造成任何影響。保留這種重定向，不僅會使瀏覽器出現討厭的跳轉，更重要的是會破壞模板的頁面識別，導致模板在目標頁面下無法加粗。不如全部刪除，以絕後患。--Yangfl（留言） 2018年1月5日 (五) 07:51 (UTC)

(－)反對，編輯摘要仍會紅字的，而且當繁簡轉換器失靈時，失靈期間還有重定向作後補。導航模板的連結本來就應該使用繁簡一樣的字，繁體條目在導航使用簡體連結本來就不鼓勵，反之亦然，加粗問題應當把導航連結的繁簡修改為與條目名稱一致來解決。（事實上刪除了重定向還是要跳轉，衹是把跳轉過程改了在幕後做，而且其跳轉過程比繁簡重定向還更複雜）--街燈電箱150號 開箱維修 抄錶 檢驗證明 2018年1月5日 (五) 08:26 (UTC)

刪除繁簡重定向會發生三個問題：

  • 編輯摘要會出現紅字
  • 仰賴繁簡轉換系統，運作負擔比繁簡重定向高
  • 條目超過某個長度後，連結不會轉換

113.52.65.202（留言） 2018年1月5日 (五) 08:53 (UTC)

  • 編輯摘要紅字是假紅字，點進去以後就會自動跳轉，而且編輯摘要本來就是作為歷史出現的，有錯別字也不能改。且目前的條目早就嚴重依賴自動重定向，若是要解決這個問題，那得為每個條目都建一個同名繁簡重定向。為了避免重定向/不加粗，勢必要求在繁體文本中出現簡體字，對平常使用繁體輸入法的編者極度不友好，反之亦然。而且在幕後跳轉的體驗遠勝於在瀏覽器跳轉，在瀏覽器跳轉會出現明顯的卡頓，對讀者不友好。--Yangfl（留言） 2018年1月5日 (五) 09:07 (UTC)
    • 沒有了繁簡重定向，載入時間會其實更卡，因為幕後要多做一次搜索、轉換、緩存轉換結果、跳轉、事後刪除緩存，有繁簡重定向就衹有跳轉便行了。假紅字使人誤會在管理上比改手動改繁簡還要困擾。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2018年1月5日 (五) 09:21 (UTC)
      • 歷史記錄本就不是面向最一般讀者的，作為管理本身就要判斷一下，顯然是要優化讀者的體驗而不是少部分管理的體驗。對於熱門頁面，所有結果都是緩存住的，無論有沒有重定向都沒有影響。有重定向，在瀏覽器端體現為302，中國區到美國的rtt至少是200ms，而且還會更差。有一次重定向，打開頁面的時間就要多加半秒不止，相比之下哪個更卡？--Yangfl（留言） 2018年1月5日 (五) 09:37 (UTC)
        • 無論冷熱門，明顯也要多做一次搜索才知道哪個頁面的緩存才對，多做一次表示服務端多了動荷，伺服器有更大負擔，縮短壽命。而且像管理員所說，繁簡轉換壞掉要怎麼辦？沒修復之前就只有躺著讓人看紅字？還有轉換限制問題要用重定向解決，每個都建立一個同名重定向其實真的較好。113.52.65.202（留言） 2018年1月5日 (五) 10:13 (UTC)
          • 伺服器縮短壽命？XD，伺服器不用才掉價，你以為是桌面電腦？每個都建重定向，量級至少是十萬級別，那才是真正巨大的負擔。繁簡轉換開了那麼多年，未見有壞的情況，而且我說的是純繁簡重定向，不含用字有差異的重定向。真要壞了還是考慮怎麼打開網站的問題吧。--Yangfl（留言） 2018年1月5日 (五) 10:31 (UTC)
            • 繁簡轉換是動態負擔，重定向是靜態負擔，一個動態負擔用的資源比千萬個靜態負擔較重，所以一定是會減壽的，而且伺服器換硬碟應該比換CPU更容易吧。繁簡轉換以前是有壞過許多次，在故障的時候很多條目變成滿堂紅我也是見過的。--113.52.65.202（留言） 2018年1月5日 (五) 11:06 (UTC)
              • 無所謂動態負擔還是靜態負擔，wiki緩存機制決定了不管是什麼頁面，哪怕是純文字，都會有緩存，除非全局禁用緩存，不然這個動態負擔一定會存在。炸掉只是偶爾一兩次，我認為不應該為這不足1%的時間影響了99%的體驗。--Yangfl（留言） 2018年1月5日 (五) 11:56 (UTC)
                • 下面的測試證明了缺少重定向會產生較長的讓人討厭的跳轉時間，動態負擔明顯是加了，刪除重定向才真的是影響讀者體驗啊~-113.52.64.53（留言）
對於伺服器性能問題，請看Wikipedia:不要擔心性能。——路過圍觀的Sakamotosan 2018年1月8日 (一) 01:26 (UTC)
對於載入速度，我就找兩個條目實測了10次，其實不論有無重定向都有出現了302：
  • 在搜索欄輸入沒有做重定向的繁體「于斯納爾斯貝里市」連到簡體「于斯纳尔斯贝里市」條目，總載入時間平均花了2.66秒，302部份平均花了887ms
  • 在搜索欄輸入有做重定向的簡體「2004年澳门华榕大厦纵火案」連到繁體「2004年澳門華榕大廈縱火案」條目，總載入時間平均花了1.89秒，302部份平均花了355ms
而且後者條目長度比前者還要長，後者有重定向下竟然還要比前者無重定向更快，可見繁簡轉換不但沒有改善載入體驗，繁簡轉換反而比重定向來得更差更卡。最後補個實測數據：
次 于斯納爾斯貝里市
（透過繁簡轉換） 		2004年澳門華榕大廈縱火案
（透過繁簡重定向）
302時間(ms) 總時間(秒) 302時間(ms) 總時間(秒)
1 984 2.9 322 1.79
2 718 2.39 313 1.95
3 781 2.5 438 1.84
4 827 2.51 314 1.95
5 937 2.82 469 1.86
6 1234 3 423 1.9
7 765 2.62 313 1.64
8 734 2.47 297 1.72
9 812 2.51 330 2.22
10 1078 2.86 328 2.01
平均 887 2.658 354.7 1.888
--街燈電箱150號 開箱維修 抄錶 檢驗證明 2018年1月5日 (五) 13:24 (UTC)
這個之前不是討論過了嗎？討論的結果就是我的bot，自動掛{{繁簡重定向}}。--Antigng（留言） 2018年1月5日 (五) 14:36 (UTC)
這個題目不知炒了多少次冷飯了—— 囧rz... --街燈電箱150號 開箱維修 抄錶 檢驗證明 2018年1月5日 (五) 14:50 (UTC)
簡而言之：沒壞別修。要找出所有符合條件的重定向要花費多少人力/給機器人編程調試時間？要建立規定後長期維護又要消耗多少人力/機器人力？為啥不節省下來幹別的？—菲菇＠維基食用菌協會 2018年1月6日 (六) 18:21 (UTC)

反對。這裡面含有編輯歷史，shizhao上回把周潤發的重定向刪除了，被刪除後無法透過直接點擊找回（看不到那時候的編輯紀錄了，要找回那個重定向必須從shizhao刪除日誌當中找）。等於把2004年以前，簡體用戶與繁體用戶互相為對方建立重定向的歷史性舉動從直觀的檢索方式上一點一滴給抹除了。不要以為沒有壞處，這種刪除正在抹除中文維基的歷史。--Jasonzhuocn（留言） 2018年1月7日 (日) 03:35 (UTC)

如果保留繁簡同等重定向，可以讓頁面一次性加載（重定向跳轉被內化到相應頁面請求中），不用依賴於繁簡轉換生成的隱藏302跳轉。反而是連結解析部分無法識別重定向為解析頁面時的預填黑才是bug吧。總之，沒壞別修。——路過圍觀的Sakamotosan 2018年1月8日 (一) 01:31 (UTC)
我支持刪除繁簡重定向。我也覺得繁簡重定向的用戶體驗不連續且糟糕，各種quirk不值得節省下來的處理器時間。看了街燈的時間對比，我覺得這個overhead完全可以接受。不一定要積極的清除掉所有的繁簡重定向，但是主編想刪哪個刪哪個是可以的。Bluedeck 2018年1月10日 (三) 14:30 (UTC)
刪除重定向才是真正的體驗不連續和糟糕，因為重定向後會被系統內化，載入時不需要找尋跳轉，刪除了後系統沒有了內化定向，系統要每次找尋，刪除繁簡重定向造成的不連續事實是長了。--113.52.65.21（留言）
採用軟體的目的就是要將複雜度內化而不呈現在用戶面前，就算為此付出處理時間也是值得的。「事實上，網站沒有任何內容時服務器性能才是最好的，但這樣的話要維基百科還有什麼意義呢？」——WP:不要擔心性能。Bluedeck 2018年1月11日 (四) 14:52 (UTC)
你們才沒資格說不要擔心效能，因為你們支持刪除重定向的其中一個理由是宣稱要減少瀏覽器出現討厭的跳轉，你們本身已經是擔心效能。113.52.80.230（留言） 2018年1月11日 (四) 15:46 (UTC)
"要減少瀏覽器出現討厭的跳轉"這是擔心UX不是擔心效能。Bluedeck 2018年1月12日 (五) 02:42 (UTC)
瀏覽器的302跳轉時間和次數越多意味著傳輸掉失的風險越多，若在網路較差的環境，刪除繁簡重定向令讀者載入失敗而要重載的潛在機會變大，這才真的更多地令用戶體驗不連續和糟糕，刪除繁簡重定向事實上才是影響用戶體驗。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2018年1月12日 (五) 04:56 (UTC)
這兩個方法都是一次302啊，其中時長的區別來自後端繁簡轉換邏輯，所以沒有這個問題。Bluedeck 2018年1月12日 (五) 21:28 (UTC)
您也懂得說「時長的區別」啊——怎麼可能沒有問題啊……時長越多表示了不連續得越多，也表示瀏覽器逾時而掉線的機率越多。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2018年1月12日 (五) 23:47 (UTC)
某個操作響應超時的概率只和請求次數相關，這兩個請求次數都是2，沒有更容易超時的問題。Bluedeck 2018年1月14日 (日) 22:40 (UTC)
超時機率當然不衹和請求次數相關啊……2次請求之間的時間越長表示掉失第二次請求的機會越多。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2018年1月15日 (一) 05:10 (UTC)
不是這樣的，兩次請求之間的時間越長，說明第一次請求的處理時間長，和第二次請求會不會更容易掉線無關。請求1處理完了關閉之後開始請求2的那一刻起，這個請求2和任何一個獨立請求都沒有區別。Bluedeck 2018年1月15日 (一) 22:25 (UTC)
「第一次請求的處理時間長」這個已經夠了，因為第一次做長了，錯過趁網路還好的時候做第二次的機會變大，兩個請求事實上或多或少都會有關係。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2018年1月15日 (一) 23:37 (UTC)
不是這樣的，實際上一點關係也沒有。伺服器處理請求的耗時並不是網絡穩定性的諸多因變量之一，網絡穩定性仿佛投色子，不會因為等久一點再投，色子的某個結果的機率就變大或變小。你可以在網絡穩定性良好的localhost做long polling，第一個請求等二十分鐘再返回，第二個請求一樣強壯。Bluedeck 2018年1月17日 (三) 05:53 (UTC)
兩次請求是讀者由按下連結至載入完成的這一整個過程的必經階段，怎麼都不可能視為無關係，而且網路穩定度的確是兩次傳輸之間的時間越短則得到較接近的結果的機會越大，才不是投骰子那般沒時間觀的道理。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2018年1月17日 (三) 15:31 (UTC)
街燈君，不是這樣的。。。。HTTP是個無狀態協議。和投色子是一樣的。Bluedeck 2018年1月20日 (六) 00:46 (UTC)
呃……這不僅是HTTP的考量來的。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2018年1月20日 (六) 05:45 (UTC)
那是什麼考慮？跟HTTP沒關係，跟TCP和更下層的協議就更沒關係了。Bluedeck 2018年1月21日 (日) 00:18 (UTC)
(つ°ω°)つ 淺藍雪 Bluedeck 2018年1月21日 (日) 01:34 (UTC)
我本來就是想說說新重定向的問題，這個討論卻向意想不到的方向發展了，(╯￣Д ￣)づ╧═╧ 淺藍雪❉ 2018年2月3日 (六) 14:12 (UTC)

說來有趣，由於我好奇伺服器究竟是怎麼處理的，我自己做了一次實驗，結果和街燈君的試驗結果正相反。那麼，從我的請求來看，我發現從任何一個重定向方式發起的頁面請求而言，伺服器根本不反返回302，直接返回200，也就是說兩個重定向方式都不增加請求的次數。此外，街燈君的試驗方法也有問題，不管街燈君的「總時間」一欄中採用的是dom ready還是window ready事件，都是包含了大量不相關資源的加載時間的。我們在乎的是第一個200的返回時間，根據這個實驗[6]的運行結果，10次對無繁簡重定向的請求時間平均為76.2毫秒，有繁簡重定向的請求回應時間為94.3毫秒。也就是說不經由繁簡重定向的方式處理的反而更快。這個試驗結果和街燈的不同的原因可能有幾個：1、我使用的是 /zh/ 前綴，也就是「不轉換」前綴，因此排除頁面內文轉換和重新渲染的時間，不知道街燈是否也是這麼測試的。2、我在測試之前清空了緩存。3、我的測試地點是美國東岸，可能連結到的WMF伺服器不一樣。歡迎大家採用代碼和這個更加科學的測試手段測試，看看是得到和我相同還是相反的結果。總之就目前的情況來看，不採用重定向的效能和用戶體驗都是更佳的。Bluedeck 2018年1月21日 (日) 19:29 (UTC)

原來用搜尋欄和直接連結的效果是不一樣啊，搜尋欄的確會出302，但直接按連結則無302。我測試是使用一個傀儡帳戶並把參數設置還原到默認值來試（除了內容語言變體設為zh），地點在澳門，也清空了cache，而直接連結我重新試了各10次，第一個200的時間兩者是相若的，無繁簡重定向平均為430.2ms，有繁簡重定向平均為425.6ms；即是說在我那邊直接連結的話單看第一個200的效果幾乎一樣，但用搜尋欄的話明顯是有影響的（先一個302後才出第一個200），因為多出了一段較長的的302時間（我已經另外再用搜尋欄多試了各10次，302時間還是無重定向的較長），結果還是有繁簡重定向的體驗佔優。（之前上面的測試，由於都是在默認設置狀態，所以渲染的東西除條目內容外都是一樣的，而上面被用作測試無重定向的條目內容（14.76KB）都比有重定向的（16.9KB）要少，所以無重定向要渲染的東西應比有重定向要少，但時間仍較多，所以「包含了大量不相關資源的加載時間的」根本不成為推翻我結果的理由）--街燈電箱150號 開箱維修 抄錶 檢驗證明 2018年1月22日 (一) 07:32 (UTC)
不相關資源指的是dom樹解析、動態渲染和外部資源DNS，處理和下載的時間。這些項目的時間有很多外部隨機變量無法控制（比如解析dom樹時CPU scheduler的行為），這個和條目長短不一定正相關，所以我說是無關變量，予以排除。Bluedeck 2018年1月28日 (日) 21:19 (UTC)
"刪除所有的純繁簡重定向"是要刪掉舊的吧。--Temp3600（留言） 2018年2月10日 (六) 17:35 (UTC)

維基百科:命名常規與維基百科:重定向

本主題或以下段落文字，移動自WP:VPP。執行者：--J.Wong 2018年4月22日 (日) 10:33 (UTC)。

近期參與存廢討論（[7]），注意到一個問題：一些維基人認為「蘿蔔蘿科瑟」一類標題「不符命名常規」。若是按照其思路，以命名常規中多條方針與其比對，確不符；但細看命名常規：「儘量使用人、物或事項的最常見的名稱」、「請使用最常見且不混淆的名稱」、「請儘量不要使用簡稱或縮寫來命名條目」等數句，明顯表明該方針不適用於重定向頁。而WP:R中「不刪除的理由」中數句與該方針互相矛盾，故部分維基人會持有「命名常規是方針，而WP:R並未達成共識，故方針優先」之觀點。若如此將該方針用於所有條目（包括重定向和消歧義），絕大多數重定向頁也許根本不該存在。重定向頁亦屬於條目名字空間，個人認為命名常規應將其包括在內。另外，建議儘早討論出一個合適的重定向方針：從以上我所述之觀點來看，目前提刪重定向，除了最後那一小章節的方針（只針對外文重定向）之外，無據可考。

如條件允許，我希望參與該存廢討論的幾位維基人：@Lnnocentius、Super Wang、RabbitMeow、Sanmosa、Shwangtianyuan能夠參與討論。

以上，yελεтς 2018年4月10日 (二) 17:16 (UTC)

  • 如@Wong128hk所述，我個人的觀點亦是「不應擴大命名常規到主名字空間的所有頁面標題」。只是當下提刪重定向，確是按照《命名常規》的。所以個人也想了解一下大家有沒有好的提議。這樣按照命名常規提刪定是不可行的。--yελεтς 2018年4月11日 (三) 04:31 (UTC)
  • @Super Wang：蘿蔔確實是原創譯名沒錯，但是若真如您所說，到時因此提刪，所依據的方針指引又是什麼？建議能將《重定向》修改後作爲方針使用，否則就如@Shizhao所述，「命名常規所適用的『條目』不包括重定向」，故提刪重定向無據可考。--yελεтς 2018年4月11日 (三) 07:26 (UTC)
  • @Super Wang：確實如您所說，兩頁面相矛盾。在這裏再次說明一遍情況：
  • 欲於「蘿蔔蘿科瑟」之存廢討論投票，故閱讀《命名常規》，得出該重定向該刪除的結論；
  • 查看《重定向》，從「不刪除的理由」中得出該重定向該保留的結論；
  • 重新閱讀《命名常規》後，發現該命名常規如我所述，根本不適用於重定向頁，但重定向頁亦屬於條目名字空間；
  • 但因《重定向》非方針而《命名常規》爲方針，且重定向頁屬於條目名字空間，只能按照《命名常規》的規定做決定。
從上得出兩種可能：
  1. 《命名常規》適用的「條目」爲「條目名字空間」，即「主名字空間」，而重定向亦屬於主名字空間。則依《命名常規》，絕大多數重定向都應該刪除，甚至重定向這一概念也不應存在；
  2. 《命名常規》適用的「條目」定義即WP:條目中所述之定義，故「消歧義與重定向都不算是一個條目」，如此則缺少重定向方針（《重定向》並非方針），提刪重定向無據可考，也許演變爲依據提刪者心情及常識判斷。
因參與討論的幾位維基人也都支持修改，故：提議將《重定向》略作修改後作爲指引或在命名常規中加入重定向部分。--yελεтς 2018年4月11日 (三) 07:54 (UTC)
@Yelets：刪除重定向顯然並不實際，建議將WP:R修改後定為方針。--Super Wang （一百萬分的感謝！） 2018年4月11日 (三) 09:15 (UTC)
請參考WP:條目，重定向和消歧義頁面都不算作是一個條目。而從統計上來說，則是重定向和沒有wiki連結的都不算是條目--百無一用是書生 (☎) 2018年4月11日 (三) 07:17 (UTC)
@Shizhao：但主名字空間確實又稱「條目名字空間」，《命名常規》定義不明。--yελεтς 2018年4月11日 (三) 07:22 (UTC)
問題不清，請直接指出哪句產生混亂。另外，提刪重定向可依據《刪除方針》。--J.Wong 2018年4月11日 (三) 08:34 (UTC)
個人認為仍需補充重定向的命名常規，現在完全沒有重定向命名標準可言。--yελεтς 2018年4月11日 (三) 15:42 (UTC)

小弟以前的重定向不會GG吧...--Temp3600（留言） 2018年4月11日 (三) 16:14 (UTC)

@Yelets：沒看到「又稱」的來源。條目名字空間是條目所在、所屬的名字空間，不等於該名字空間裡的頁面都為「條目」（如重定向、消歧義頁）。「明顯表明該方針不適用於重定向頁」不一定準確，Wikipedia:命名常規開篇稱「命名常規，是關於如何命名一個頁面的指導方針」，而後續細則有些限定條目（如「使用中文」），有些又稱頁面（如「必須精準簡練」），這些可能需斟酌並修訂。--YFdyh000（留言） 2018年4月11日 (三) 22:46 (UTC)
@YFdyh000：可能我表述不準確，所以原創研究了。主名字空間的頁面，無論是消歧義還是重定向，左上都標示「條目」，且「名字空間」的模板{{Namespaces}}里「主」和「條目」也是並列標示的，至少會造成誤解。--yελεтς 2018年4月12日 (四) 13:11 (UTC)
前者似乎為習慣及翻譯問題，英文界面中為Page（頁面）。後者的並列顯示可以理解，說「主名字空間」可能有人不明白，並列為「/」可理解為擇一使用。--YFdyh000（留言） 2018年4月12日 (四) 17:12 (UTC)
@YFdyh000：但後者並列確實造成一定誤導，很容易理解成該名字空間有兩個名稱。--yελεтς 慶祝百萬條目達成 2018年4月13日 (五) 17:21 (UTC)
《維基百科:什麼是條目》，《命名常規》是給條目用的，而重定向與消歧義並非條目。——白布飄揚（留言） 2018年4月13日 (五) 17:06 (UTC)
@白布飘扬：請您看看上面幾句討論。--yελεтς 慶祝百萬條目達成 2018年4月13日 (五) 17:16 (UTC)

中文維基是否需要非中立但普遍使用的條目/重定向名稱？

本主題或以下段落文字，移動自WP:VPP。執行者：--J.Wong 2018年5月19日 (六) 03:38 (UTC)。

近期我參與維基百科:頁面存廢討論/記錄/2018/05/04關於「馬桶台、CCAV、金三胖」三個重定向是否需要提刪的討論，說這些重定向「違反維基百科WP:NPOV規則，維基百科不是隨意踐踏於他人（機構）的地方」。後來我在英文維基提刪了「CCAV」的重定向，但英文維基編者認為，在某些情況下，重定向可以使用非中立但普遍使用的名稱（條目名稱也是一樣，而且這一方針以前我都不知道，這幾天才知道，參見英文維基重定向指引、英文維基命名常規方針）。這些在英文維基早已成為方針，然而在中文維基還沒有達成共識。為此，我決定在此發起討論，就中文維基是否可以使用非中立但普遍使用的條目名稱/重定向名稱進行探討。--Shwangtianyuan 有事請給我打☎ 2018年5月6日 (日) 06:50 (UTC)

我認為：寫一個條目說明台巴子是可以的，但將其重定向到台灣人則不當。--【和平至上】💬📝 2018年5月11日 (五) 08:47 (UTC)
同意和平至上的意見，除非能在條目中說明該外號，不然直接重定向是不合適的。->>Vocal&Guitar->>留言 2018年5月11日 (五) 09:06 (UTC)

提議修改WP:RDRNC

本主題或以下段落文字，移動自WP:VPP。執行者：--J.Wong 2018年7月10日 (二) 04:34 (UTC)。

已通過及修訂：
經公示，本提案通過，確立《重定向》非中文重定向問題段落僅適用於主名字空間。--J.Wong 2018年7月7日 (六) 05:03 (UTC)
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

在Template:Taiwan_theme的VFD中-Zest君提到該方針只適用於主名字空間，我想了一下，事實也確實如此，所以建議做以下修改：

現行條文

根據投票，維基人達成共識，同意建立下列數種非中文重定向頁：

...（略）...
8. 化學品CAS號：文獻中所記載的每種化合物的唯一編碼，如106-98-9→1-丁烯。
提議條文

根據投票，維基人達成共識，同意建立下列數種非中文重定向頁：

...（略）...
8. 化學品CAS號：文獻中所記載的每種化合物的唯一編碼，如106-98-9→1-丁烯。

注意：以上限制只適用於主名字空間。

--相信友誼就是魔法的User:萌得不能再萌CuSO4正在努力提高知識水平 2018年6月29日 (五) 13:19 (UTC)

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

提議將Emoji重定向列入WP:RDRNC

本主題或以下段落文字，移動自WP:VPP。執行者：--J.Wong 2018年9月15日 (六) 12:43 (UTC)。

完成：公示7日期間並無任何異議，故通過--Z7504非常建議必要時多關注評選（留言） 2018年9月10日 (一) 14:32 (UTC)
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

近來AfD討論中出現了提刪Unicode字符Emoji重定向的例子（如Wikipedia:頁面存廢討論/記錄/2018/08/03#🤔），之前亦有過AfD後保留的先例，但方針《RDRNC》中並未表明此類重定向可以保留，存廢判斷的標準也只是「此類重定向已有一定通用性」。故在此討論標題所述之舉是否得當、若得當該如何修改。

  • 英文維基百科相關項目頁面：en:WP:REMOJI（列出供參考）

--Yelets 2018年8月5日 (日) 09:58 (UTC)

  1. 有些字符跳轉到對應條目有一定價值，能了解字符的含義，如©️、®️、™️。☎️、☯️、♻️等跳轉也能接受，查詢所代表的含義和介紹。
  2. 但🤔到思考就是用表情表達含義、文字的範疇了，很懷疑有多少人這樣搜索。以及該跳轉到對應含義，還是跳轉到emoji相關列表（存廢討論有人提出）。
  3. 有些可代表多種含義的表情，該按Unicode實體（定義）名解釋，還是按常見用途，或者新建或重定向到消歧義。
  4. emoji目前有一千餘個。「🅰️」要重定向到A嗎，感覺基本沒必要。「Emoji等Unicode字符」範圍太大了，很多字母的異體、音調字符。
  5. 一例，☘的實體名和重定向目標是酢漿草，但表情用者有多少人了解和用來表達這個植物呢，至三葉草可能更恰當。--YFdyh000（留言） 2018年8月5日 (日) 15:51 (UTC)
把章節標題改爲了僅針對Emoji重定向，而不包括其他Unicode字符，後者導致範圍過大且目前暫無討論必要。以下是個人看法：
  1. 「有多少人這樣搜索？」重定向暫無專有的方針決定存廢，個人認爲建立有理有據、符合相關方針指引等規定即可。有人建立就代表有人會這麼搜索。
  2. 「該跳轉到對應含義，還是跳轉到emoji相關列表？」兩種皆可說得過去：跳轉到對應含義是因爲這個符號代表該含義，而跳轉到Emoji列表是因爲這個符號是Emoji。而目前的慣例是重定向到對應含義，故傾向於此。
  3. 「「🅰️」要重定向到A嗎，感覺基本沒必要」同第一點。
  4. 「☘的實體名和重定向目標是酢漿草，但表情用者有多少人了解和用來表達這個植物呢，至三葉草可能更恰當。」個人認爲應該重定向到實體名，「三葉草」則屬於原創研究。即使可能造成歧義，但據實體名建立重定向並無問題，實際上也達到了「查詢所代表的含義和介紹」之目的。英文維基百科的相關討論結果大致是「無歧義保留，有歧義可提請刪除」。但個人認爲有歧義與否較難界定且大多依賴主觀判斷，故不提倡在條文中涉及。--Yelets 2018年8月5日 (日) 20:09 (UTC)
1存疑，fans條目同理，可能只有創建者或極少數的幾個人如此搜索。2是部分考慮多義或系列表情的用法和資料性。3同1。4的部分理由是三葉草內容更廣泛，且其中介紹了酢漿草，不過改善酢漿草條目可做到類似目的。如果能批量創建和格式規範化，也許好一些。--YFdyh000（留言） 2018年8月7日 (二) 11:16 (UTC)
針對4，可在酢漿草條目中加入「其Unicode符號是☘」等相關信息。--Yelets 2018年8月7日 (二) 11:30 (UTC)
現提議爲：
(＋)傾向支持，如同🔒和鎖一樣；但表示十分存在必要性。—— だ＊ぜ 謹此敬上 留言Comment𓋹簽名Signature 2018年8月8日 (三) 14:23 (UTC)
(＋)支持：應該沒有大的紕漏。每次在AFD爭得面紅耳赤，不如寫進規定。-- Hal 2018年8月9日 (四) 05:55 (UTC)

看樣子共識已經形成了。按照慣例，公告欄公示七日，如有意見請速提出。-- Stang 2018年9月3日 (一) 14:13 (UTC)

@Z7504：(：)回應「Emoji」不僅指面部表情，見表情圖標條目。另外我更名了，您ping以前的名字是ping不到我的。--ॐVijaya 2018年9月5日 (三) 04:04 (UTC)
@Stang、Duhshala：複通知，已過7天公示期，應已通過--Z7504非常建議必要時多關注評選（留言） 2018年9月10日 (一) 14:31 (UTC)
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

提議允許使用ISO 639代碼作為語言重定向

本主題或以下段落文字，移動自WP:VPP。執行者：--J.Wong 2018年9月16日 (日) 11:23 (UTC)。

有的時候查找一些語言，因為並不知道語言的名稱（比如說是維基孵育場之類的）而為查找語言帶來了困難。

因此在此建議允許此類座位重定向。有關重定向的內容，需要使用【ISO 639:】前綴，後方跟上ISO 639-3代碼（代碼表索引：{{ISO639-3Navigation}}）即可。

例如頁面【ISO 639:zho】會重定向到漢語、頁面【ISO 639:eng】會重定向到英語、頁面【ISO 639:nan】會重定向到閩南語，以此類推。

因此提議修改《重定向方針·非中文重定向問題》章節，增加以下一行：

現行條文

非中文重定向問題 根據投票，維基人達成共識，同意建立下列數種非中文重定向頁：

1.學術名稱：科學用語、計算機技術等的專門用語、動植物的學名，這些詞語是字典里查不到的，例：Homo sapiens→人。
（略）
提議條文

非中文重定向問題 根據投票，維基人達成共識，同意建立下列數種非中文重定向頁：

1.學術名稱：科學用語、計算機技術等的專門用語、動植物的學名，這些詞語是字典里查不到的，例：Homo sapiens→人。
（略）
9.ISO 639代碼：ISO 639-3代碼表索引中的語言列表，例：ISO 639:zho→漢語。

夢蝶葬花@生涯不敗 2018年8月30日 (四) 08:05 (UTC)

這種規定未免太有針對性，太細節了--百無一用是書生 (☎) 2018年8月31日 (五) 02:53 (UTC)
@Shizhao： 並沒有。只是針對那一個列表，做出來一個方便進行查找語言的重定向而已。可以從代碼表中的語言用機器人或flood跑一遍做重定向。--夢蝶葬花@生涯不敗 2018年8月31日 (五) 05:54 (UTC)
為什麼不查表，而要用重定向。匹配到條目正文/信息框記錄的信息更好。沒有zh-CN、zh-hans等，用處不大的樣子。--YFdyh000（留言） 2018年8月31日 (五) 04:51 (UTC)
@YFdyh000： 有時候別人根本就找不到列表在哪，這時候這類重定向就應該用上了。像你提到的zh-CN、zh-hans什麼的，這裡是用不上的。因為本身就是無效的ISO 639代碼。--夢蝶葬花@生涯不敗 2018年8月31日 (五) 05:54 (UTC)
@五月雨恋歌：有多少人在用這個代碼呢，zho有什麼用，很少用到。若已知ISO 639，站內搜索有更高的匹配成功率。--YFdyh000（留言） 2018年8月31日 (五) 06:25 (UTC)
@YFdyh000： 中文用的不多是真的，但是站內搜索有時候還是找不到的。隨便找一個比較偏的語言，那麼站內搜索能找到嗎？--夢蝶葬花@生涯不敗 2018年9月1日 (六) 13:58 (UTC)
沒有看到該編碼有足夠的關注度（使用率）來單獨豁免和以前綴批量建立，也不認為會有幾個人用此前綴。--YFdyh000（留言） 2018年9月1日 (六) 19:09 (UTC)
提案人是否想過可以使用WP:ISO 639/xxx的格式來完成這個任務呢？不一定要用主名字空間解決。Bluedeck 2018年9月1日 (六) 22:33 (UTC)
是否確定絕大多數語言都在中維有條目?--Temp3600（留言） 2018年9月8日 (六) 06:29 (UTC)
取自「https://zh.wikipedia.org/w/index.php?title=Wikipedia_talk:重定向/存檔3&oldid=68206423」