维基百科讨论:字词转换/存檔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”