打开主菜单

维基百科讨论:字词转换

(无题)编辑

简体称“软件”(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)

  • (:)回應我建议放在左栏的“帮助”或者“工具”里面,加一个“使用HTTPS安全连接”的链接 ——Star Brilliant留言) 2012年6月15日 (五) 10:59 (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)

  •   已修复,感謝回報。—Chiefwei - - ) 2014年10月8日 (三) 06:38 (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)

這些人是叫「張傑」還是「張杰」?编辑

這裡。-- 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日
User:Hidayetullah暂时没有对语法的自动转换,估计今后在技术上也难以实现,只能用手动转换了,例如-{zh-cn:帮他的忙;zh-tw:幫忙他}-。 --dqwyy (talk) Ohtori Chihaya 2017年12月2日 (六) 02:51 (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)
  • (-)反对:繁簡重定向屬於zh版維基百科中不可或缺的--Z7504非常建議必要時多關注評選留言) 2018年1月13日 (六) 05:09 (UTC)
  • (-)反对,jasonzhuocn的理由已然足夠。--Temp3600留言) 2018年1月15日 (一) 16:41 (UTC)
  • (+)支持不覺得這種東西有什麽不可或缺的,1秒的延遲毫無所謂,先不說掉綫不掉綫,就算掉綫又能有多少?寫條目還要改模板才是真的煩。我對刪除舊的重定向沒什麽看法,只是覺得沒有任何必要建立的新的重定向--淺藍雪 2018年1月20日 (六) 16:58 (UTC)
(つ°ω°)つ 淺藍雪 Bluedeck 2018年1月21日 (日) 01:34 (UTC)
我本来就是想说说新重定向的问题,这个讨论却向意想不到的方向发展了,(╯ ̄Д  ̄)づ╧═╧ 淺藍雪 2018年2月3日 (六) 14:12 (UTC)
  • (=)中立,至少已经存在的繁简重定向就留着吧。--暗中观察的RabbitMeow 与此喵对话 風の辿り着く場所 2018年1月21日 (日) 10:35 (UTC)
  • (-)反对,不要擔心性能沒錯,但那是針對維基媒體基金會的伺服器而言,針對用戶端多少還是得考慮性能。從街燈電箱150號的實測結果來看還是保留繁簡重定向為妙。只是這樣的話編者就要留心導航模板是不是會有因連結繁簡弄錯而變成重定向頁的情況。凡是不能兩全其美。--RekishiEJ留言) 2018年1月21日 (日) 13:47 (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)
  • (=)中立,讀完以上的討論,本人覺得大量的繁簡重定向仍然有其必要性存在,不應全數刪除。--Janee談笑風生 2018年1月22日 (一) 09:24 (UTC)
  • (+)支持:既然已有字詞轉換系統,就毋須多餘的繁簡重定向。如果連地區詞轉換都可以仿效繁簡轉換處理的話,那就能省下更多的重定向。--M.Chan 2018年1月23日 (二) 03:43 (UTC)
  • (-)反对,月經性提議。Walter Grassroot留言) 2018年1月23日 (二) 03:47 (UTC)
  • (-)反对有时链接会出错,而且费事。--Ξぞ曱۩·💬· 2018年1月31日 (三) 20:46 (UTC)
  • (?)疑問:你们真nb,为什么老繁简redirect和新繁简redirect被混为一谈?  以及街灯的意思不是说新的也要建立吧?-- SzMithrandirEred Luin 2018年2月9日 (五) 20:41 (UTC)
"删除所有的纯繁简重定向"是要刪掉舊的吧。--Temp3600留言) 2018年2月10日 (六) 17:35 (UTC)
  • (-)反对,有時自动转换還是會出錯,例如鍾嶼晨事件在我建立繁體重定向之前使用繁體字根本無法連結到條目。--M940504留言) 2018年2月12日 (一) 15:43 (UTC)
    • 这种情况自然不在删除范围之内。有别的反对原因吗?Bluedeck 2018年2月14日 (三) 07:55 (UTC)
  • (-)反对:对用家不友善。我不想再引起條目繁简争论了。— 強烈抗議英文維基百科禁止使用右旋「卐」,甚至左旋「卍」作為簽名一部分 2018年2月23日 (五) 03:31 (UTC)
  • (?)疑問: for "模板在目标页面下无法加粗", why don't you edit the template then?--Mongolian Beef留言) 2018年3月2日 (五) 15:42 (UTC)
  • (-)反对:避免出现重复条目(尤其外挂机器人创建新条目时),避免过度依赖转换系统(尤其手机版APP经常出现简繁空链不自动跳转的问题),重定向本身并不占多少空间,社群不必浪费时间来重复处理这些本来不是问题的问题。——白布飘扬留言) 2018年3月6日 (二) 01:39 (UTC)
  • (-)反对,转换系统相较于重定向过于复杂,更容易出现问题(比如修改转换规则会一次性影响很多页面等等问题)。EtaoinWu讨论 2018年3月9日 (五) 07:20 (UTC)
  • (=)中立:已有不必删,若无不需加。-- by ---DW- at 2018年7月17日 (二) 15:54 (UTC)

能不能在錯誤修復的注意事項加個請不要再加標題的提醒?编辑

發現有些人會在錯誤修復時自己又加了個標題,這是沒必要的,可不可以請在那個注意事項加個請不要自己再加標題,直接提報錯誤的轉換即可?--阿鈞有事請留言 2018年5月8日 (二) 10:56 (UTC)

馬來西亞和新加坡编辑

是否應該提供馬來西亞與新加坡用字模式但是使用繁體字的轉換選項,以符合當地有這種用字模式的人的閱讀習慣?——C933103(留言) 2018年9月28日 (五) 09:57 (UTC)

回到项目页面“字词转换”。