跳至內容

維基百科討論:字詞轉換/存檔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」