维基百科

维基百科讨论:重定向/存档3

< Wikipedia talk:重定向
Wong128hk在话题“提议允许使用ISO 639代码作为语言重定向”中的最新留言：6年前

纯简繁重定向有必要么？

最新留言：在8年前发布15条留言10人参与讨论

本主题或以下段落文字，移动自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:随机页面

最新留言：在8年前发布4条留言4人参与讨论

本主题或以下段落文字，移动自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)

中英混用的外语重定向问题

最新留言：在8年前发布4条留言4人参与讨论

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

以外文为主加一个中文表意文字的外文专有名词重定向是否该建立是需要近一步讨论的，在WP:RDRNC“学术名称：科学用语、电脑技术等的专门用语、动植物的学名，这些词语是字典里查不到的”中只有提到全外文的学术名称可以建立其重定向，但没有讲明以外文为主加一个中文表意文字的外文专有名词重定向是否合适，且也有混用被删除的案例，比如Wikipedia:页面存废讨论/记录/2016/09/09#Szilassi多面体，因此发起此讨论--　宇帆（普通留言·Flow留言·联络） 2016年10月16日 (日) 17:43 (UTC)

毛主席，蔡总统等名称

最新留言：在8年前发布18条留言7人参与讨论

本主题或以下段落文字，移动自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)

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

最新留言：在7年前发布9条留言7人参与讨论

本主题或以下段落文字，移动自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)

是否应该让国外名人的人名重定向？

最新留言：在7年前发布49条留言28人参与讨论

本主题或以下段落文字，移动自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)

重定向问题

最新留言：在7年前发布8条留言5人参与讨论

本主题或以下段落文字，移动自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)

有关英文名称的重定向连结

最新留言：在7年前发布57条留言15人参与讨论

本主题或以下段落文字，移动自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)

提议：开放外语重定向

最新留言：在7年前发布58条留言13人参与讨论

本主题或以下段落文字，移动自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)

非中文重定向

最新留言：在7年前发布39条留言10人参与讨论

本主题或以下段落文字，移动自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号重定向

最新留言：在6年前发布30条留言14人参与讨论

本主题或以下段落文字，存档自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)

关于游戏条目英文原名是否应当重定向的问题

最新留言：在6年前发布6条留言6人参与讨论

本主题或以下段落文字，存档自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号重定向后续讨论

最新留言：在6年前发布47条留言9人参与讨论

本主题或以下段落文字，移动自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)

删除所有的纯繁简重定向

最新留言：在6年前发布56条留言25人参与讨论

本主题或以下段落文字，移动自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)

维基百科:命名常规与维基百科:重定向

最新留言：在6年前发布36条留言10人参与讨论

本主题或以下段落文字，移动自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)

中文维基是否需要非中立但普遍使用的条目/重定向名称？

最新留言：在6年前发布10条留言8人参与讨论

本主题或以下段落文字，移动自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

最新留言：在6年前发布8条留言5人参与讨论

本主题或以下段落文字，移动自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

最新留言：在6年前发布19条留言11人参与讨论

本主题或以下段落文字，移动自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代码作为语言重定向

最新留言：在6年前发布12条留言7人参与讨论

本主题或以下段落文字，移动自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”
返回到项目页面“重定向/存檔3”。