跳转到内容

维基百科讨论:字词转换/存档1

页面内容不支持其他语言。
维基百科，自由的百科全书

（无题）

简体称“软件”（IT名词），在正体称为“软件”， 而在简体称“软体”（生物学名词），在正体也称为“软件”， 怎么解决？--120242pp (留言) 2009年5月9日 (六) 10:26 (UTC)

希望能把“全文手工转换”的使用方法或者模板加以更改，主要的想法是把具体转换条目（如“大陆：博客；台湾：部落格；香港：网志；新加坡：博客； 当前用字模式下显示为→博客 ”）转移到页面的最后方。因为现在将其放在最开始，使用手机浏览的话（包括使用wapedia），由于没有折叠功能，会把所有转换内容全部显示出来，会很不方便，特别是对于“物理学”之类的模板，非常长。

我知道这可能会很麻烦，但希望能够加以考虑。 --- [.Z]是个超没性格的人|正在努力成为维基小正太 --- 2009年8月1日 (六) 11:48 (UTC)


李心洁的简介，简体是“鬼后”，繁体中应为“鬼后”。

＊⼂ 建议字词转换（含系统转换、公共组转换等）将标题一并纳入，如果可能的话最好也能加入自动重定向功能。这样一来可以省去标题参数必须另外增加的困扰，另一方面则可以让不同中文语系的使用者能够用自己的惯用语来搜寻，而不需要再做重定向。--Gonbom (留言) 2009年11月24日 (二) 07:28 (UTC)

幺与么

在一个讨论汉字字形的词条绞丝旁，我想显示出幺，但是在繁体模式下，它会自动被转化为么，不符合我的原意，应该如何办？

人工转换标签只能先有zh-hans后有zh-hant或者只有zh-hans，不能直接跟zh-hant，希望能有修正。2thuriel (留言) 2010年1月31日 (日) 09:28 (UTC)

地区词转换应在所有条目中生效，而不仅仅局限在某些特定领域的条目。如“程式”“软体”“西元”在所有页面中都应转换，否则很容易造成理解困难。希望能有修正。

错误转换：支持者→支援者

请修复支持者→支援者；错误案例：Mozilla Firefox：，Mozilla基金会号召支援者买下纽约时报全版广告，刊登即将在11月释出的Firefox 1.0。短短十天的募捐活动已经获得来自一万人的25万美元捐款；希望重新整理健力士世界纪录中“单日最多人下载软件”的一项。支援者需预先到推广网站Spread Firefox登记，在Fx 3.0发布当日便会收到电邮提示参与活动Y200000012 (留言) 2010年5月9日 (日) 13:23 (UTC)

请求修复公共转换组的NBA组，公共转换失效。

公共转换组的NBA组失效了，转换组地址http://zh.wikipedia.org/w/index.php?title=Template:CGroup/NBA&redirect=no 请修复。例子，如保罗·皮尔斯条目，使用NBA公共转换组后在港澳繁体却没有转换成港澳译名。 楷叔讲古 (留言) 2011年5月28日 (六) 23:16 (UTC)

注：此处原有文字，因为与本讨论页面无关，已由Symplectopedia (留言)于2011年9月16日 (五) 09:34 (UTC)删除，尚祈见谅。若有异议请至互助客栈或向管理员反映。


字体显示错误

为什么高山滑雪条目中的曲字，在编辑完显示出来是麹。ㄚ文 (留言) 2011年12月1日 (四) 08:23 (UTC)

简体“只能”，繁体亦写成“只能”，不是“只能”，而“萤幕”则正写为“荧幕”。因为“萤”字解作发光器官的甲虫，为萤火虫。

建议增加一个避免触发大陆防火墙的转换

首页或者转换下拉菜单加上https的链接，或者其他方法，现在知道用https访问的大陆用户非常少。薰衣草毒药 (留言) 2012年2月1日 (三) 15:43 (UTC)

在"不登入"的情况下, 香港地区字体显示错误

在香港地区使用维基百科搜寻资料, 如果没有登入, 字体会显示为简体中文, 而香港人书面上使用的母语一直以来都是繁体中文, 请跟进这个问题.

明年的维基人年会(Wikimania 2013)会在香港举行, 如果连香港地区的一般搜寻都出现母语显示错误, 到时实在是贻笑大方.—以上未签名的留言由Stephentsang2000（对话｜贡献）加入。

错误转换：徘徊于“斗”牛之间 -> 徘徊于“斗”牛之间 (前赤壁赋)

请修复“徘徊于斗牛之间”，此处原文应为“斗”牛而非“斗”牛，“斗”牛之“斗”此处为“斗宿”之意，非战斗之意。错误案例：前赤壁赋

已修复。 --琅琊醉（留言） 2015年2月13日 (五) 02:22 (UTC)

对于同一个词在不同领域下意思不同时的转换

举例：计算机行业，大陆：“软 件”，港澳台：“软 体”，英语：“software”；生物学/物理/计算机3D建模，大陆：“软 体”，港澳台：“软 体”，英语：“soft body”；（我在词中间打上了空格迫使它在被你们浏览的时候不会被转换）

甚至在同一个词条中都可能有不同的意思，如“某某3D游戏引擎软 件(software)支援刚体(rigid body)、软 体(soft body)、流体(fluid)的物理模拟。”

又例如“在某某战役中，某军队增加火力支 援，各地民众支 持某军队。”

首先，根据条目名称中消歧义的括号里的内容自动判断是否转换并且怎样转换，另外希望增加一个template，在编辑的时候对于某一个特定的词进行作用范围在本词条（或者是某一个词、或者template之后内容）的替换。

——Star Brilliant（留言） 2012年6月15日 (五) 10:59 (UTC)

单双引号的繁简转换问题

简体的双引号“”转换为繁体时并未转换成‘’而是“”，同样简体的单引号‘’转换成了‘’。 ——文孟周（留言）2012年7月13日（五）14:17（UTC）

这是正确无误的，大陆的双引号对应台湾的单引号，大陆的单引号对应台湾的双引号。你需要看一下中华民国（台湾）教育部的标点符号说明。-- By LNDDYL.（留言） 2015年6月29日 (一) 03:00 (UTC)

于卉乔 与 於卉乔 问题

台湾某知名爆红人物于卉乔，在于卉乔条目内，被过度翻译成於卉乔。

--Scott88514（留言） 2012年8月27日 (一) 01:33 (UTC)

错误转换：“戴安娜_(歌手)”姓氏被错误转换成繁体“黛”

此艺人为“戴”为真正之中文姓氏，但系统，被过度转换成“黛”。Meg留言 2012年11月10日 (六) 23:54 (UTC)

改版

将提交首页改版成这样可以吗？

请在提交请求前，仔细审视您提交的内容属于以下三种中的哪一类型。一般而言，如果您提交的内容可以一字一字地繁简对应，那么一般都属于繁简转换，如上面的“打斗”与“打斗”之例；如果您提交的内容不能一字一字地繁简对应，如上面的“巴伦西亚”、“巴伦西亚”与“巴伦西亚”，其中“巴”、“华”、“瓦”都不是繁简对应的同一个字，那么请您提交地区词转换候选。此外，过度转换的修复都请提交到错误修复中去。

无运作的Wikipedia:地区词转换候选

  1. 就连非常合理的转换提案都没人参与投票，这里要怎么继续运作?
  2. 请问Wikipedia:地区词转换候选#投票通过的依据提到的投票资格是维基百科:人事任免投票资格吗?

－Towatw（留言） 2013年2月28日 (四) 11:16 (UTC)

荧幕 与 屏幕

！ 在Wordpress词条发现使用了“荧幕截图”（大陆简体模式），怀疑是大陆与港澳台的说法不太一样，请考证一下。User670839245（留言） 2013年3月6日 (三) 20:33 (UTC)

维基百科的分词系统应加强

公理系统条目中“完全形式化”被被转换为“完全角式化”，“半形式化”被转换成“半角式化”。 上述现象是因为维基百科将“完全形式化”中的“全形”看成一个词语，转换成了“全角”， 将“半形式化”的“半形”看成一个词语，转换成了“半角”。 因此希望维基百科的分词系统能够避免此类错误。 ——张秦川（留言）2013年10月1号(二）20:58

抱歉维基百科没有启用任何分词系统，在将来很长一段时间内也不会启用分词系统。你说的问题要人手工分词，比如中间加入-{}-。--Gqqnb（留言） 2014年10月7日 (二) 03:18 (UTC)

台湾繁体中文转换问题

在许多条目中，从大陆简体转换至台湾正体时几乎没有更动，造成阅读的困难。 比起大陆简体，台湾正体可能比较接近香港繁体，或许可以考虑将台湾正体中大部分的字词转换至香港繁体，比较能接近台湾正体使用者的需求，敬请改善。 ——YehTzuChen（留言）2014年3月20日(四) 15:17(utc)

关于该项目正文不用简繁体转换的原因为何？

关于该项目正文不用简繁体转换的原因为何？--萌动の心 请给我电报哦 2014年4月21日 (一) 18:06 (UTC)

现在显示不了“出错页面”一项

何故？--578985s（留言） 2014年10月7日 (二) 16:05 (UTC)

有一个疑问

既然1986年的《简化字总表》已保留“覆”，那为什么还要把“复”转换成“覆”？--578985s（留言） 2014年10月18日 (六) 10:11 (UTC)

传统上復、複、覆本就有字义重叠。在大陆，“覆”是个曾被简化为“复”，尔后又恢复的字。在这个过程中部分词义转嫁到了“复”身上，没有恢复回来。而港台地区在相关词语上则多以覆为正统，造成了目前用字不同、需要转换的局面。—Chiefwei（论 - 编 - 历） 2014年10月19日 (日) 12:36 (UTC)
查了下，是不是凡是“遮盖”、“翻转过来”的意思就用“覆”？--578985s（留言） 2014年10月19日 (日) 14:35 (UTC)
是的。—Chiefwei（论 - 编 - 历） 2014年10月20日 (一) 08:37 (UTC)

介绍开源繁简转换工具OpenCC，提议采用其字典

介绍摘自OpenCC的Github Repo https://github.com/BYVoid/OpenCC ：

Introduction 介绍
Open Chinese Convert (OpenCC, 开放中文转换)中文简繁转换开源项目，支持词汇级别的转换、异体字转换和地区习惯用词转换（中国大陆、台湾、香港）。
Features 特点
  • 严格区分“一简对多繁”和“一简对多异”。
  • 完全兼容异体字，可以实现动态替换。
  • 严格审校一简对多繁词条，原则为“能分则不合”。
  • 支持中国大陆、台湾、香港异体字和地区习惯用词转换，如“里”“里”、“鼠标”“鼠标”。
  • 词库和函数库完全分离，可以自由修改、导入、扩展。
  • 支持C、C++、Python、PHP、Java、Ruby、Node.js。
  • 兼容Windows、Linux、Mac平台。

大家发现维基上有错误的替换，可以去这里：http://opencc.byvoid.com/ 试试看，如果成功的例子很多，我就研究下怎么对接他的词典。

--琅琊醉（留言） 2015年2月13日 (五) 02:09 (UTC)

OpenCC是个不错的转换工具，但是同样存在一些问题。例如在单字部分，其过于拘泥台港两地官方标准，而不考虑当地媒体和民众实际的使用情况。地区词部分，其过度偏重IT词汇，导致其他领域语句极易过度转换，而维基百科包罗万象，必须周全考虑各领域的问题。
繁简转换没有万全之策，转换错误只能慢慢弥补。不客气地说，目前站上提报的错误转换，OpenCC基本也做不好。即便抛开对接技术上的问题不谈，一味采用他人词典，而放弃自己多年来的积累，个人也觉得并不可取。—Chiefwei（论 - 编 - 历） 2015年2月13日 (五) 02:30 (UTC)
补充一下，现在我们面临的最大问题不是词典是否全面，而是Gerrit上龟速一般的代码审核与合并效率。考虑到服务器加载速度的问题，我们甚至不能让词典“太过全面”，有时可能还需要做取舍。OpenCC和本站采用的转换技术原理没有差别，因此在更好的技术出现以前，个人看不到对接的必要。倒不如说，如果真的对接了，这边极慢的代码更新速度反而会带来更多问题。—Chiefwei（论 - 编 - 历） 2015年2月13日 (五) 02:38 (UTC)

这些人是叫“張傑”还是“張杰”？

本主题或以下段落文字，移动自Wikipedia:互助客栈/求助。执行者：Jimmy-bot（留言） 2015年2月19日 (四) 08:42 (UTC)。

这里。-- By LNDDYL.（留言） 2015年2月9日 (一) 02:00 (UTC)

人名中有用“杰”的，也有用“傑”的，维基百科的字词转换如何处理这种情况？-- By LNDDYL.（留言） 2015年2月9日 (一) 02:04 (UTC)

我提醒一下各位“傑”是“傑出”的“傑”，简体字“傑”、“杰”不分。-- By LNDDYL.（留言） 2015年2月9日 (一) 02:12 (UTC)

关于铁路部分

大陆用“站台”、港澳台用“月台”；大陆用“运营”、港澳台用“营运”也可以全局转换吗？这些词语还蛮普遍的。--owennson（聊天室、奖座柜） 2015年5月11日 (一) 10:51 (UTC)

关于特殊页面的无转换备忘

找到了，phab:T36832，曾经有设定允许启用，后来已经删除了。——路过围观的Sakamotosan 2016年2月3日 (三) 06:19 (UTC)

字词转换出错，萤幕蔽???

防火长城：2015年5月19日起中文维基百科被完全“屏蔽”，在繁体中文下会显示“螢幕蔽”。--秋意假发浓(我已关闭了所有通知，所以@我看不到)（留言） 2016年8月22日 (一) 04:00 (UTC)

全屏。--Jimmy Xu 论 2016年8月22日 (一) 04:06 (UTC)
已显示正常，谢谢您--秋意假发浓(我已关闭了所有通知，所以@我看不到)（留言） 2016年8月22日 (一) 04:18 (UTC)

非繁简转换的转换

维基百科有154个页面中含有“既刊”一词，这个词是日文，意思是已发行的作品，多见于日本漫画、动画为主题的条目，但并不是中文。请问这种无关繁简的转换可不可以提交？应该提交到何处？KRF（留言） 2016年10月1日 (六) 07:24 (UTC)

这里是中文维基百科，用语应使用中文，日文用语请直接修改源码。—Chiefwei（论 - 历） 2016年12月9日 (五) 07:32 (UTC)

有关马新地区的字词转教

虽然马新地区官方采纳了简体字，但貌似在当地社会活动特别是较年长者之间，主要采用的文字依然是繁体字。要个马新繁体的tab吗？——C933103(留言) 2016年12月9日 (五) 01:25 (UTC)

以官方语言用字为准。—Chiefwei（论 - 历） 2016年12月9日 (五) 07:31 (UTC)
我的意思是提供另一选项？——C933103(留言) 2016年12月9日 (五) 07:49 (UTC)
如果不是官方语言用字的话就难以衡量选择标准，比如里的繁体是用裡还是裏，这没有办法解决。另外新的标签也会增加维护成本，就像大陆也有不少长者以及爱好者惯用繁体，但是也没有列入维基百科转换。—Chiefwei（论 - 历） 2016年12月9日 (五) 12:22 (UTC)
参照实际使用不就行了吗…例如用google在.my域名之下用||操作符来搜索以""包起来的那两个字来搜索，结果包括当地新闻网站在内大部分当地繁体网页都是用裡字符…。
维护工作量是个问题嗯…
——C933103(留言) 2016年12月16日 (五) 09:16 (UTC)
或许可以参考一下CLDR上的所谓“香港简体（zh-hans-hk）”与“澳门简体（zh-hans-mo）”。--Liuxinyu970226（留言） 2017年2月1日 (三) 04:34 (UTC)

在没有明显转换错误的情况下，可以对现有转换提出修改么

如果可以，点按哪个按钮提交请求？--Liuxinyu970226（留言） 2017年2月1日 (三) 04:37 (UTC)

请问哪里有对语法的转换？

本人在阅读中国大陆简体维基中发现大量条目中的内容出现病句或歧义。后来才意识到是使用其他中文书面语的编辑完成了内容后直接繁简转换的结果。比如：

  • “了”与“有”：任意一动词的完成时的肯定式，在中国的书面语正确表达的“……了”，而在台湾的正确表达的似为“有……”。当然，二者在任意一动词的完成时的否定式上的差别不大：中国“没……”，台湾“没有……”。二者的区别在于，中国的书面语语法中，在“有”后面是不能跟随动词的，只能跟随名词。
  • “得”与“得到”：在中国的书面语语法中，可以被得到的事物是在被得到后发生了所有权改变的事物。而可以被得的事物则没有这个特点。而台湾书面语语法似不使用“得”，“得”与“得到”都使用“得到”。如“罹患了癌症”的表达：中国书面语的正确表达为“得了癌症”，而台湾书面语则是“得到了癌症”。
  • 动名词与动词的差异：在中国的书面语的动名词，在台湾书面语是直接当动词用的。
  1. 如“对第三人施以帮助”的表达：中国书面语的正确表达为“帮他的忙”、“给他帮忙”；而台湾书面语则是“帮忙他”。
  2. 如“对第三人施以帮助”的完成时的表达：中国书面语的正确表达为“帮了他的忙”、“给他帮了忙”；而台湾书面语则是“有帮忙他”。
  Hidayetullah (留言) 2017年10月27日
@Hidayetullah：暂时没有对语法的自动转换，估计今后在技术上也难以实现，只能用手动转换了，例如-{zh-cn:帮他的忙;zh-tw:幫忙他}-。 --dqwyy (talk) Ohtori Chihaya 2017年12月2日 (六) 02:51 (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的返回时间，根据这个实验[1]的运行结果，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)

能不能在错误修复的注意事项加个请不要再加标题的提醒?

发现有些人会在错误修复时自己又加了个标题，这是没必要的，可不可以请在那个注意事项加个请不要自己再加标题，直接提报错误的转换即可?--阿钧※有事请留言 2018年5月8日 (二) 10:56 (UTC)

马来西亚和新加坡

是否应该提供马来西亚与新加坡用字模式但是使用繁体字的转换选项，以符合当地有这种用字模式的人的阅读习惯？——C933103(留言) 2018年9月28日 (五) 09:57 (UTC)

中国大陆的繁体转换

有人偏好于繁体字，是否应当提供符合大陆用词模式和大陆繁体标准的转换选项？--NousYoubing（留言） 2019年12月26日 (四) 07:12 (UTC)

台湾中文字形为 繁体中文字。（准确地表达中国话）—以上未签名的留言由2601:196:4701:F040:7CB9:86C2:AEBD:FD7A（对话）于2020年8月21日 (五) 05:07 (UTC)加入。

iOS APP地区词字词转换Bug

本主题或以下段落文字，移动自Wikipedia:互助客栈/技术。执行者：Jimmy-bot（留言） 2021年3月4日 (四) 16:14 (UTC)。

范例表格 iOS APP地区词字词转换Bug
问题 地区词字词转换在iOS APP页面内的内文及页面标题是正常的，但各个小标题(副标？)则时有时无，但使用safari在网页看是正常的。应该是APP 的Bug，不确定是不是在这里回报～

--アレックス（留言） 2021年2月9日 (二) 15:00 (UTC)

关于质素 素质 与 品质（质量）

不清楚当前这个港台地区常用的“质素”一词目前是怎么做地区转换的。就目前而言我很难在大陆语境里面见到“质素”一词，表达相同含义有“品质”（“质量”有其它物理学含义，按下不表）。中文维基也有词条品质对这个词的地区转换做了解释。然而我在用google搜索中文维基里面含有“质素”的词条的时候，发现部分词条内自动将“品质”转换成了“质素”（维基专题：美国），但是“质素”却不见得一定转换为“品质”（维基百科：动员令）。同时，源代码使用“质素”一词的页面不在少数。仅按简繁体转化，“质素”让人联想到“素质”，细想却又发现所用并非此意。想问一下当前维基是怎么转化这些词的？--TBBnozomi（留言） 2021年3月30日 (二) 20:55 (UTC)

搜索结果界面的繁简过度转换错误

比如“孙乾”，在这个条目界面可以正确转换，选择简体仍然是“孙乾”，但 搜索结果界面 显示成了“孙干”，并且没有选择简繁的地方。如果这个界面无法做到正确转换，建议就不要转换了，保留原样反而更好。──以上未签名的留言由Betty（讨论｜贡献）于2021年10月29日 (五) 04:45 (UTC)加入。

条目目录没有简繁转换

本主题或以下段落文字，移动自Wikipedia:互助客栈/技术。执行者：Jimmy-bot（留言） 2021年11月17日 (三) 08:14 (UTC)。

于Phabricator查看
编号T295187的任务

刚刚发现所有条目的目录都没有对段落标题进行简繁转换，请问是哪里出问题了？--Tim Wu（留言） 2021年11月5日 (五) 09:55 (UTC)

于Phabricator查看
编号T295091的任务

为何新编辑的维基百科条目的只有有些字词自动转换？

　　最近，我编辑了名为“摸金之诡棺伏军”条目（以香港繁体中文撰写，且十分肯定已将国际化语言及内容语言变体改为“zh-Hant-HK（中文（香港））”），但当我们将此条目转换为台湾繁体（亦即台湾繁体中文维基百科所称之台湾正体）版后，遂发现“网络（部首应为‘糸’）”仍未转换为“网络”（此为台湾用词，而“路”的部首应为“足”（我之所以要如此注解，只因将本评论发布后，发现所输入之“网络（部首应为‘糸’）”的台湾用词“网络（部首应为‘足’）”被自动改为其香港用词“网络（部首应为‘糸’）”；然我再编辑时，就发现该台湾用词自动转为“网络（部首应为‘足’）”。为免因此而混淆，故我将以下不同用词以部首及其他相关字词注释此等要解释的不同用词，以防系统无法转换此等已注释之不同用词；即使有些不同用词已经转换了，但仍能依照其部首及其他相关字词提示得知其正确的用词及其写法））。此外，我于十多天前编辑完“斯里卡里穆尼安迪庙”条目（已被删除）后，再将其转换为大陆简体版后，发现有一词汇“刹车”转换为“刹（应为简体字词汇‘罗刹’之‘刹’）车”。然而，我最近阅读其他条目时，发现用词转换得十分正常，如将“雪（应为‘雪地’之“雪”）糕（应为‘糕点’之‘糕’）”条目转为台湾繁体版后，发现，“雪（应为‘雪地’之‘雪’）糕（应为‘糕点’之‘糕’）”、“忌（应为‘禁忌’之‘忌’）廉（应为‘廉洁’之‘廉’）”等词皆能转换为“冰淇淋（其部首应为‘水’且‘淇淋’应为‘Cream’之音译）、“鲜（应为‘新鲜’之‘鲜’）奶（应为‘牛奶’之‘奶’）油（应为‘油画’之‘油’）”等，以及在“牛（应为‘牛头马面’之‘牛’）油（应为‘油画’之‘油’）”条目中，“牛（应为‘牛头马面’之‘牛’）油（应为‘油画’之‘油’）”等词亦能转换为“黄（应为‘黄色’之‘黄’）油（应为‘油漆’之‘油’）”。其他则不再赘述。（本评论乃于香港繁体中文版面撰写。我是香港人。）--赵学勤（留言） 2022年11月26日 (六) 09:18 (UTC)

大家亦可学习我如此注释，以防自己所输入且必要表达的字词被系统转换（笑言）。--赵学勤（留言） 2022年11月26日 (六) 09:18 (UTC)
原来要输入noteTA才能有字词自动转换的效果。--赵学勤（留言） 2022年11月30日 (三) 13:00 (UTC)

建议对所有公共转换组中转换规则的修改全部集中讨论

本主题或以下段落文字，移动自Wikipedia:互助客栈/其他。执行者：Jimmy-bot（留言） 2023年4月19日 (三) 16:14 (UTC)。

一来目前各个公共转换组中转换规则的编辑请求都是在各自的讨论页进行，非常分散，不容易集中维护；二来许多对公共转换组中转换规则的修改都是直接编辑，缺乏讨论（无保护的转换组）；三来各个公共转换组中彼此重复的转换规则已经超过了11000多笔，很可能造成许多转换冲突，或不必要的重复转换。因此希望能有一个集中的地方讨论公共转换组的转换规则，目前比较方便的地方就是Wikipedia:字词转换，建议大致如下：

  1. 在Wikipedia:字词转换新增一个“公共转换组转换”部分，既可以专门用于讨论公共转换组规则，也可以根据讨论情况，直接转交全域转换，可以避免一些重复讨论的问题，也可以权衡不同转换组之间的冲突和重复
  2. 建议所有公共转换组转换规则都应该集中在Wikipedia:字词转换先行讨论过之后，再放入转换组；或者：
  3. 所有公共转换组转换规则的编辑请求都应集中在Wikipedia:字词转换进行充分讨论后再修改

--百無一用是書生 (☎) 2023年3月28日 (二) 07:02 (UTC)

(＋)支持：目前的公共转换组太容易让人感到困扰了。--DoroWolf（留言） 2023年3月28日 (二) 12:12 (UTC)
提案合理，目的亦合理，(＋)支持。Sanmosa Συ γάρ μοι και μοίρα εί και τύχη 2023年3月28日 (二) 12:13 (UTC)
基本同意。不过有没有必要修订方针或指引？—— Eric Liu 創造は生命（留言・留名・学生会） 2023年3月28日 (二) 12:17 (UTC)
@Ericliu1912：应该有，因为《保护方针》的规定是“如果希望编辑被保护的页面，用户可以在对应的讨论页使用{{editprotected}}模板来请求并说明”，而现在有为数不少的转换组是受到半保护、模板保护或全保护的，至少就后两种情况而言，如果不修改方针或指引，我依例还是得在转换组模组的讨论页提请编辑请求。Sanmosa Συ γάρ μοι και μοίρα εί και τύχη 2023年3月28日 (二) 12:34 (UTC)
这个在转换组对话页面加一个编辑提示不就行了？--百無一用是書生 (☎) 2023年3月28日 (二) 12:45 (UTC)
这样的话会引伸出编辑提示与方针指引相悖的疑虑，稳妥起见还是调整一下《保护方针》的规定比较好，至少也加个但书。我没仔细看其他方针指引条文，不排除还有其他方针指引也需要这种但书。Sanmosa Συ γάρ μοι και μοίρα εί και τύχη 2023年3月28日 (二) 15:53 (UTC)
不过“对应的讨论页”没有说一定要是公共转换组本身的讨论页呀，完全可以是集中讨论页面（ —— Eric Liu 創造は生命（留言・留名・学生会） 2023年3月29日 (三) 02:33 (UTC)
@Ericliu1912、Shizhao：好像也是，那应该是我多虑了吧。Sanmosa Συ γάρ μοι και μοίρα εί και τύχη 2023年3月30日 (四) 11:04 (UTC)
我认为完全没必要，虽然“如果希望编辑被保护的页面，用户可以在对应的讨论页使用{{editprotected}}模板来请求并说明”,但是我只是在转换组对话页做出特殊说明，提醒对于转换规则的讨论集中在xxx处进行，完全和保护方针不冲突（其他非转换规则的编辑请求仍然是在相应对话页继续进行）。而且集中讨论又不是强制的，用户仍然可以在讨论页提交编辑请求修改规则，只是可能进度会很慢而已。--百無一用是書生 (☎) 2023年3月29日 (三) 03:26 (UTC)
根据2023年2月的修订，已经没有转换组使用模板保护以上层级的保护。--Xiplus#Talk 2023年3月29日 (三) 02:50 (UTC)
另根据Wikipedia:保护方针#使用和处理编辑请求：“受保护的页面上编辑时...应该确保相应问题已经在讨论页提出，并已取得共识”，但又有“管理员和模板编辑员在处理编辑请求时，应根据以下情况采取相应措施”，似乎表示：只有“管理员和模板编辑员”编辑模板保护以上层级的页面时才需遵照“处理编辑请求”的规定；未经讨论直接编辑半保护或延伸确认保护似乎没有任何问题。--Xiplus#Talk 2023年3月29日 (三) 02:54 (UTC)
建议在字词转换集中讨论区提交请求后，也在相关条目顶部挂上“地区词规则更改请求横幅”（类似移动请求），以更广泛地征求各地编者和读者的意见。（提名时给出主要条目连结，机器人代挂模板也可。）说实话处理转换组的人员就那么多，而且这东西还分领域；比如擅长搞足球转换组的未必能在IT组上提出意见，这东西还是需要熟悉领域来参与。--洛普利宁 2023年3月29日 (三) 14:07 (UTC)
挂模板不太现实，转换组涉及的条目少则几个，多则数十数百，怎么挂。正因为转换组分领域，而各个领域之间的转换有可能交叉、冲突，集中讨论就容易避免这种情况--百無一用是書生 (☎) 2023年3月30日 (四) 02:30 (UTC)
我的意思是在转换规则对应的条目挂模板。比如zh-cn:超级计算机; zh-tw:超級電腦; zh-sg:超级电脑;的请求就在超级计算机条目挂模板。
跨领域问题集中讨论是很好的，但关键是要有相关领域的人来参与。转换组的内容很多不到全域转换级别，只靠general knowledge还是比较难判断的，如果不能吸引相关领域的人士，感觉还是很难有进展。所以怎样吸引相关领域编辑也是重要的话题。（中维喜欢大小讨论都上客栈，结果就是现在没有发展出领域级的集中讨论区。但转换组规则发客栈通知是“破事水”，发对应条目讨论页通知效力又不够，感觉很坑。）--洛普利宁 2023年3月30日 (四) 13:54 (UTC)
另外或许应该考虑出一篇转换组指南，介绍一些原则。比如IT组是否过于肥大，应该拆分成“电脑图形学”“信息科学”“软件用语”“硬件用语”“网络用语”等几个不同的领域？像网站类条目和IT组大部分规则根本没有交集，但只能被迫接受整个转换组，容易被过度转换。--洛普利宁 2023年3月30日 (四) 14:09 (UTC)
转换组指南非常必要，但是我暂时没什么想法。。。。--百無一用是書生 (☎) 2023年4月6日 (四) 02:19 (UTC)
第二、三点假如是强制性的话，就不支持。社群人手不足。--Ghren🐦🕙 2023年3月30日 (四) 14:58 (UTC)
  • 真可怜，独裁社群明明在字词转换请求上都没什么人愿意处理了，还敢提出集中讨论？笑死。与其这样，不如勤劳点多多在条目用上{{NoteTA}}还比较快吧。你们到底是把维基百科写给读者看的，还是真的就那种自我陶醉写给自己看的？可悲的独裁社群，正常的读者是不可能来陪这个独裁社群搞什么集中讨论的。--Z7504非常建议必要时多关注评选（留言） 2023年4月8日 (六) 17:24 (UTC)
    阁下要四处怨叹而不作为到什么时候？您也是“独裁社群”的一分子，别自命清高。—— Eric Liu 創造は生命（留言・留名・学生会） 2023年4月8日 (六) 20:39 (UTC)
    谁跟这个独裁社群不作为了？难道{{NoteTA}}模板都是假的、装饰的啊？可悲可悲。首页显示的字词都已经管理的和这个字词转换请求一样松散了还有脸讲话，比如常见的“千米/公里”、“信息/資訊”都搞不定了，根本完全无法说服读者嘛。还有这个独裁社群还忘记一点：要字词转换前，还可能得先把至少几十组、几百组常用的字词背熟透才行。因为中国、香港的用户不见得一定要了解台湾的用词是什么，反之亦同。读者或编者都没有义务去背这些字词的使用方式。如果没能力，那真的是所谓的笑死刚好而已。--Z7504非常建议必要时多关注评选（留言） 2023年4月9日 (日) 14:52 (UTC)

是否要全部使用类推简化字？

比如“鵎鵼”，使用其类推简化字“𱉻𱊊”。--Bczhc（留言） 2023年7月14日 (五) 12:51 (UTC)

铃芽之旅的中文配音员叫“胡云旗”，在繁体字是否转换错误？

“云”在繁体字作例子：不知所云、古人云、文言助词。--Piggy Studio（留言） 2023年8月3日 (四) 02:53 (UTC)

名字里一般不作动词吧。——暁月凛奈 (留言) 2023年8月3日 (四) 04:00 (UTC)
取自“https://zh.wikipedia.org/w/index.php?title=Wikipedia_talk:字词转换/存檔1&oldid=81666045”