跳转到内容

维基百科:互助客栈/技术

维基百科,自由的百科全书

这是本页的一个历史版本,由Liangent留言 | 贡献2016年6月18日 (六) 05:44 →‎“1.66米(5尺5寸)(166 cm)”编辑。这可能和当前版本存在着巨大的差异。

本頁用作讨论在编辑时遇到的技术问题;發表問題或討論前,請先參閱常見問題解答帮助信息MediaWiki基本問題及搜索舊討論記錄。另請注意:

請注重礼仪、遵守方針與指引,一般問題請至互助客棧其他區知识问答提出,留言后请务必签名(点击 )。


發表前請先搜索存档,參考舊討論中的内容可節省您的時間。
公告欄
# 💭 話題 💬 👥 🙋 最新發言 🕒 (UTC+8)
1 我的Wikiplus无法在除Edge之外的浏览器使用 11 3 自由雨日 2024-08-07 17:16
2 2024年第31期技術新聞 6 5 Cwek 2024-08-04 17:06
3 考虑统一一下内联标签的样式? 4 4 SunAfterRain 2024-08-04 15:11
4 哈佛注脚中日语字的转换问题 7 5 FradonStar 2024-08-04 19:03
5 2024年第32期技術新聞 3 3 魔琴 2024-08-10 22:53
6 Template:Lang 4 2 Kethyga 2024-08-10 20:39
發言更新圖例
  • 最近一小時內
  • 最近一日內
  • 一週內
  • 一個月內
  • 逾一個月
特殊狀態
已移動至其他頁面
或完成討論之議題
手動設定
當列表出現異常時,
請先檢查設定是否有誤

正在廣泛徵求意見的議題

以下討論需要社群廣泛關注:重新整理

維基百科技術議題與模板

Wikipedia:徵求意見/深色模式 § 導言

近期部署的深色模式(Dark mode)对页面内容带来了很多兼容性问题,需要修复。可参考mw:Recommendations for night mode compatibility on Wikimedia wikis

修复工作需要修复许多模板、模块以及小工具,还有个别的页面也需要修复。这个征求意见的目的一是需要很多人帮忙查找问题并修复,二是一些页面如何修复可能会影响到页面本身的用色、排版设计,需要进一步讨论寻求共识。

--百無一用是書生 () 2024年6月22日 (六) 12:34 (UTC)

MediaWiki talk:Gadgets-definition § 提議引入CollapsibleToggle作為預設啟用可選擇關閉的小工具

日前的討論將多個使用NavFrame的模板切換成了一般的mw-collapsible導致這些模板不再能透過點Head來展開或關閉,故在此提議引入CollapsibleToggle來讓這些模板可以恢復以前的行為。同時此小工具也為其他類型的mw-collapsible提供點未隱藏的區塊來展開的功能,具體測試樣例可以參考[1](Beta Cluster)。--SunAfterRain 2024年8月4日 (日) 13:23 (UTC)

“導航Popup”這個術語的翻譯未完成,想知道修改是否合適。—John Doe 120talk2016年5月24日 (二) 02:45 (UTC)[回复]

(+)支持(是叫“弹出式导航"?)--Artoria2e5 更改·工具 2016年5月26日 (四) 15:19 (UTC)[回复]
支持弹出式导航--Gqqnb留言2016年6月2日 (四) 00:20 (UTC)[回复]
惯例,改和不改没什么影响。——路过围观的Sakamotosan 2016年6月2日 (四) 01:03 (UTC)[回复]
这个译名已经长期使用成为约定俗成,所以没需要去改。——路过围观的Sakamotosan 2016年6月8日 (三) 00:34 (UTC)[回复]
Then,弹出式导航又多了吗?这个工具在引进入来时虽然没完全译全名,但或者是觉得这个译名可以接受,然后沿用下来,所以一提及的话就肯定知道就是这个工具,所以现在改名就显得多此一举。——路过围观的Sakamotosan 2016年6月8日 (三) 08:04 (UTC)[回复]

由机器人修复跨语言链接

能否由机器人修复跨语言链接,例如将[[:en:GNU Compiler Collection|GCC]]修复为{{link-en|GCC|GNU Compiler Collection}}?现在挂{{Link style}}的页面似乎过于多了……--哪位维基人能够一下打死五个2016年5月26日 (四) 15:13 (UTC)[回复]

这样会出错的。--Antigng留言2016年5月26日 (四) 15:16 (UTC)[回复]
搞个WP:JS吧。--Artoria2e5 更改·工具 2016年5月26日 (四) 15:17 (UTC)[回复]
半自动也许可以,但是自动的bot没法判断 BBB(DDD)该怎么处理。--Antigng留言2016年5月26日 (四) 15:20 (UTC)[回复]
這個例子頂多處理成{{le|BBB|AAA}}([[CCC|DDD]]),似乎比現況好?-和平、奮鬥、救地球!留言DC14討論2016年5月26日 (四) 16:12 (UTC)[回复]
(+)支持这种处理,其实更可能出现的情况是这个例子Example)被处理成例子例子英语Example),比现在条目顶上挂着{{Link style}}强--哪位维基人能够一下打死五个2016年5月27日 (五) 16:29 (UTC)[回复]
我的想法:
  1. 對於[[:en:XXX]]:
    1. 若wikidata上存在對應中文條目YYY,則改為[[YYY|XXX]]
    2. 若wikidata上不存在對應中文條目,則改為{{link-en|XXX|XXX}}
  2. 對於[[:en:XXX|ZZZ]]:
    1. 若wikidata上存在對應中文條目YYY,則改為[[YYY|ZZZ]]
    2. 若wikidata上不存在對應中文條目,則改為{{link-en|ZZZ|XXX}}
  3. 若[[:en:XXX]]的原語言條目不存在,則直接改為[[XXX]]
以上。-和平、奮鬥、救地球!留言DC14討論2016年5月28日 (六) 02:30 (UTC)[回复]
(+)支持,两种情况下的小(!)意見
  • 對於[[:en:XXX]],若wikidata上存在對應中文條目YYY,则直接改为[[YYY]]
  • 若[[:en:XXX]]的原語言條目不存在,則直接改為XXX
--哪位维基人能够一下打死五个2016年5月29日 (日) 06:36 (UTC)[回复]
之前已經有過一次不成功的嘗試...維基百科:機器人/申請/Cewbot/11 您可參考在下的修正方法 提出進一步的意見 --Kanashimi留言2016年5月29日 (日) 10:51 (UTC)[回复]
@Dingruogu對於第一種情況,會有很多錯誤發生,例如像這樣子或者Antigng在上面Cewbot申請時舉的例子。另外@Kanashimi我的方案會產生什麼錯誤嗎?-和平、奮鬥、救地球!留言DC14討論2016年5月30日 (一) 01:13 (UTC)[回复]
我個人的想法是,其實我們會用到 [[中文項目名]] ([[:en:其他語言頁面名|...]]) 之類的,然後不存在此中文項目名的話,大多都是因為沒辦法不列其他語言頁面,要不然也找不到source,因此若存在相對應中文條目,就能直接改成 [[中文項目名]],刪掉 ([[:en:其他語言頁面名|...]]) 了。(雖然我也能保留下來就是,這是特意刪的……)相對的,就算想留原文名,也因為這是中文維基百科,只要點進中文項目名就能得到相對應資訊,根本不須多此一舉。因此之前那些測試是這麼作的。像上面舉的例子,已經是我以為無法判斷 卡耶塔諾·維羅索 = 卡耶塔諾·費洛索 的情況下,bot能做到最好的變換了。當其他瀏覽者看到這樣的轉換,應該能很容易發現兩者音近,因此能夠起到提醒瀏覽者存在中文條目、可以刪掉卡耶塔諾·維羅索的作用。就我個人而言,這是次成功地轉換。當然許多人不是這麼看的,所以我就放棄了,因為沒共識。
但若真認為需要留下原文名,那我得說不論是哪種轉換法,恐怕都會出現不理想的轉換。以我搜尋過所有 [[:en:其他語言頁面名]], [[:en:其他語言頁面名|...]] 的結果,許多人填這東西有些隨興。除了錯填,還可能出現模板、前後文特殊對應關係。因此以 Jimmy Xu 的看法,或許會說「就不用改就好了」?
總之我覺得要改這東西,以當前的標準來看,還是很冒險的。若您想知道這樣的作業可能出現那些例外,可以參考我之前的幾千次嘗試。至於我使用的方法,包括意外處理,請見GitHub上的20160414.import label from wiki link.js頁面Kanashimi留言2016年5月30日 (一) 10:51 (UTC)[回复]
同意@Kanashimi所述。我是觉得无论怎么改,都比放在那里不管强。--哪位维基人能够一下打死五个2016年5月30日 (一) 13:28 (UTC)[回复]
@Kanashimi正因為可能有「錯填、模板、前後文特殊對應關係」,所以我才提出了我那個方案。-和平、奮鬥、救地球!留言DC14討論2016年6月2日 (四) 08:46 (UTC)[回复]
@和平奮鬥救地球舉個例吧。我已經做到會偵測[[:en:...|英語版]]之類的,不過仍不能盡如人意。例如還有[[:en:Alien language|外星語言]]{{en icon}}[[:en:Gambier Islands|甘比爾]]島會轉成[[甘比爾群島]]島[[甘比爾群島|甘比爾]]島等。雖然到最後也幾乎都對應了,可惜還是沒過關就是。我相信@Jimmy XuliangentAntigng能給出更多意見。另外如前述,我不覺得 [[中文項目名]] ([[:en:其他語言頁面名|...]]) 改為 [[中文項目名]] ([[中文項目名|...]]) 之類,留下原文名會比直接刪掉 ([[:en:其他語言頁面名|...]]) 好。(這是之前我沒過的理由之一)
說實在我也希望改,可惜現在的標準我拿不清。問我不如問有決定權的人吧。若是決定好標準與共識了,鑑於之前做好的擺著也是擺著,我很願意效勞的 :) Kanashimi留言2016年6月2日 (四) 09:50 (UTC)[回复]
在尝试用AWB半自动替换,但效率较低,人工判断(错误率约1%~20%),需User:Liangent-bot二次处理蓝链。见YFdyh-bot讨论 | 貢獻)。--YFdyh000留言2016年6月4日 (六) 06:13 (UTC)[回复]
暂停,效率太低了,识别出错率不低(仅两条正则替换和最后检查[[:,有剩余就跳过;无wikidata等检查)。某些特例存在问题,比如楔形文字#音节表,替换成{{tsl}}就变成鼓励创建这些字符为单独条目了吧。--YFdyh000留言2016年6月4日 (六) 06:47 (UTC)[回复]
不要把显示文字当成条目名(比如现在最顶上的编辑),不然我的bot以后会建不合适的重定向……Liangent留言 2016年6月4日 (六) 11:51 (UTC)[回复]
Special:Diff/40359479,确实,刚开始有想着,后来看得多可能忘记这点了……--YFdyh000留言2016年6月9日 (四) 13:54 (UTC)[回复]

當{{cite journal}}的volume值大於或等於100時,會導致volume值顯示錯誤格式

茲舉二例對照如下。第一個參考文獻的「第100期」字樣缺乏粗體格式,且前面多了一個標點符號。第二個參考文獻則正常。[1][2] --Matt Smith留言2016年5月29日 (日) 02:23 (UTC)[回复]

逻辑是volume的长度<=4和>4时会分别处理;我改成<=6时和>6时会分别处理,上边的问题暂时解决了[3],但是不知道会不会引入新的问题,没敢彻底解决[4]--哪位维基人能够一下打死五个2016年5月29日 (日) 06:30 (UTC)[回复]
多謝閣下。上邊的問題解決了。短時間內應該沒有期刊會達到上萬期。--Matt Smith留言2016年5月29日 (日) 10:55 (UTC)[回复]
參考文獻(示範)
  1. ^ 作者. 文章標題. 期刊 (地點: 出版者). 2016年5月29日, 第100期. 
  2. ^ 作者. 文章標題. 期刊 (地點: 出版者). 2016年5月29日, 第99期. 
  3. ^ 作者. 文章標題. 期刊 (地點: 出版者). 2016年5月29日, 第1234期. 
  4. ^ 作者. 文章標題. 期刊 (地點: 出版者). 2016年5月29日,. 第12345期. 
(?)疑問,这样做的目的是什么呢?--Antigng留言2016年5月29日 (日) 10:58 (UTC)[回复]
原设计issue应只填数字,不应加入“第xx期”等字眼,而暂时没哪个杂志出版了上万期吧。看en的模板文档,有在issue后面填了这一issue的标题的用法,我不知道zh这边有没有这样使用,虽然用了也大概没问题,加了标题的也应该不止6个字符这么短了。Liangent留言 2016年5月29日 (日) 12:02 (UTC)[回复]
回應兩位,敝人其實不太確定學術論文的參考文獻的格式有無特別規定不可加上「第」、「期」、「Vol.」等字,敝人加上這些字只是為了讓維基讀者看懂這裡提到數字是什麼意思。--Matt Smith留言2016年5月29日 (日) 13:54 (UTC)[回复]
volume是卷号,不是期号啊....另外,有时候期刊会出特刊之类的,期号可能会不是数字。还有文献格式默认就是没「第」、「期」、「Vol.」等字的--百無一用是書生 () 2016年5月30日 (一) 01:58 (UTC)[回复]
謝謝提醒,看來敝人完全搞錯了,這裡所說的volume應該是issue才對。關於參考文獻格式,敝人剛才查看了一下條目APA格式及其外部連結,發現文獻格式真的沒有「第」、「期」、「Vol.」等字。--Matt Smith留言2016年5月30日 (一) 02:28 (UTC)[回复]
那就不要加「第」、「期」、「Vol.」等字。最多修改模板添加CSS類,讓用戶CSS可以用::before等偽類自行添加「第」、「期」、「Vol.」等字,如果他自己看不懂的話。--Gqqnb留言2016年6月2日 (四) 00:23 (UTC)[回复]
這也是個好方法。順帶一提,敝人查看了英語的{{cite journal}}和{{cite book}},發現前者不會自動幫頁碼加上「pp.」、「p.」,但後者卻會。照這樣看來,偽類若要實現,可能必須限定在特定的模版。--Matt Smith留言2016年6月2日 (四) 01:09 (UTC)[回复]
我也想順便問,可是沒規定使用「volume」或「issue」時,不能多加中文字,像「volume=第6卷」、「issue=第8期」這樣,又或是寫成「volume=Vol.6」、「issue=No.8」這樣,甚至有的人習慣用「volume=6(8)」或另一種「issue=6(8)」去寫,再不然就是有人懶得用那麼多,直接與title連著一起用,寫成「title=某文獻(6卷8期)」這樣,真的是什麼亂七八糟用法都有人。--36.233.190.185留言2016年6月10日 (五) 20:12 (UTC)[回复]

預覽頁面

在預覽頁面,「→ 前往編輯框」按鈕就在警告內容未儲存的長方形框下面,視覺上極不起眼。建議改為放在長方形內,例如在「內容還未保存。」的右邊,這樣會比較醒目。--Quest for Truth留言2016年6月4日 (六) 20:15 (UTC)[回复]

假如按鈕的形狀和顏色可以做到類似本頁的「立即發表新議題」按鈕則更佳!--Quest for Truth留言2016年6月4日 (六) 20:18 (UTC)[回复]

以上是我的構想示意圖。--Quest for Truth留言2016年6月4日 (六) 21:13 (UTC)[回复]

以上是另一個構思。--Quest for Truth留言2016年6月4日 (六) 21:19 (UTC)[回复]
MediaWiki:Previewnote/zh不包含mw-continue-editing。代码分离,只能JS调整吧。--YFdyh000留言2016年6月5日 (日) 04:44 (UTC)[回复]
請見User:Quest_for_Truth/Previewnote/zh及示範效果User:Quest_for_Truth/Previewnote

預覽

→ 前往編輯框


原来如此,好像是可行的,(+)支持。原“→ 前往编辑框”可考虑全局CSS隐藏。--YFdyh000留言2016年6月6日 (一) 08:38 (UTC)[回复]

其實這樣也不錯,可能中文維基這邊會有人慣了按長方框的左下方,沒有了連結會造成不便。反之好像我在不同語種的維基之間遊走,眼見其他語種都是在「请记住这只是预览。您的更改尚未保存!」之後附上連結的,唯獨中文維基例外,倒是有些不便。--Quest for Truth留言2016年6月5日 (日) 20:10 (UTC)[回复]

咦,我怎么发现现在预览的时候没有这个提示了?--百無一用是書生 () 2016年6月6日 (一) 02:19 (UTC)[回复]
我这里有问题啊,见截图,在编辑预览页上截的图。--Tomchen1989留言2016年6月8日 (三) 15:44 (UTC)[回复]
反正我是不用这个功能,不知道其他人用不用。#ForeverLove凡人丶 你一定要好好的 中文字数统计工具 2016年6月13日 (一) 12:11 (UTC)[回复]

@Shizhao其實除了Mediawiki:Previewnote/zh,還有

故此你無需使用「-{只}-」來避免轉換。另外,如果你要使用{{Clickable button 2}}的話,請務必使用|style=text-indent:0; background:green; color:white;來避免空格,以及控制顏色。--Quest for Truth留言2016年6月13日 (一) 15:01 (UTC)[回复]

隱藏分類與監視列表

打開 Category:需要從英語維基百科翻譯的條目‎,將此頁面加入監視列表。打開監視列表,確認頁面分類不隱藏,但是不顯示該分類的變化。然後打開參數設置 > 顯示 > 高級選擇,打勾顯示隱藏分類,刷新監視列表,顯示該分類的變化。

英語維基百科也是這樣,在 en:Wikipedia talk:Categorization上搜索 [ hidden watchlist ],沒有明顯結果,這是一個功能還是一個bug?—John Doe 120talk2016年6月8日 (三) 06:17 (UTC)[回复]

怎么启用插入代码与特殊字符的功能

英文(及其他)Wikipedia,在编辑条目时,编辑框的下面、编辑摘要的上面,有(默认就有)可以插入更多代码及特殊字符的功能,点击看截图。请问中文维基百科怎么设置启用此功能?谢谢。--Tomchen1989留言2016年6月8日 (三) 15:42 (UTC)[回复]

哦我自己找到了,在设置的“编辑工具”或是“编辑按钮扩展”里面(我刚刚把设置的“小工具”里面的东西,包括这两类编辑工具,几乎全部都给启用了,我上面说的那个功能自然也启用了)。--Tomchen1989留言2016年6月8日 (三) 22:21 (UTC)[回复]

Content Translation - Community consultation

Content Translation is an article creation tool that has been in use since January 2015. Content translation helps users translate existing articles from one Wikipedia into languages on other Wikipedias where the article does not exist. It is used by editors to write many new articles, increasing participation by new users and also renewing active editing in many Wikipedias. Translated from existing articles, 88000 new articles with considerably rich content have been written using this tool. Content Translation is an opt-in beta feature. We are now preparing to take Content Translation to a bigger group of users by taking the tool out of beta feature on a few Wikipedias. We prepared a preliminary list with the following wikis: Arabic, Catalan, Chinese, Hebrew, Indonesian, Japanese, Norwegian (Bokmal), Persian, Portuguese, Punjabi, Russian, Spanish, Turkish, and Ukrainian. This set of wikis were selected to create variations in size, language groups, and usage patterns of Content Translation.

Based on an earlier consultation with the editors of the Catalan Wikipedia, the earliest adopter of this tool, the Content Translation team have prepared a preliminary set of requirements that we consider should be fulfilled before the tool is ready for use outside of beta. To focus on the features and concerns that are most important for users of Content Translation, we would like to get more feedback. We are hosting a consultation from June 8, 2016 to June 22, 2016 on this village pump.

As we work on the tool it is being improved every day, but we are particularly looking to better understand the issues in Content Translation that make the tool unusable or add extra workload for our editors. Please let us know on this topic thread. During the conversations, we may point you to Phabricator tickets for ongoing work, so that you can track the status of work. For new issues we will create new Phabricator tickets to help the development team keep the details documented. After June 22, 2016 we will go through all the feedback and follow up with a summary, and an updated plan for Content Translation’s move out of beta.

This message could only be written in English. We will be grateful if the message can be translated for other users of the Wikipedia. Thank you for your support for Content Translation. We look forward to hearing from you! On behalf of the WMF Language team: —Runa Bhattacharjee留言2016年6月8日 (三) 17:01 (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)[回复]

efn註解有很大瑕疵,用在條目龐大內容時,出錯時該怎麼追查修正?提議廢除使用這方式

編號 測試條件 測試前 效果 測試後 效果 優與劣的說明
A 使用<ref group="註">對應<references group="註"/> [2] 正常 [3] 誤植 A任何條目皆可適用,因為沒有B這種問題(見說明)發生。
B 使用{{efn|name=注|}}對應{{Notelist}}群組 [4] 正常 [5] 誤植 B不適用於條目的龐大內容加入這種註解,必須要「注=1」、「注=2」,若新加入註解沒變更「注=1」,發生連用二個「注=1」就會出錯而無法顯示,所以必須從龐大內容中傷眼睛地去查「注=1」做修正。

經上表所見可知,建議不要使用B這種註解,如果要使用,一旦出錯要追查去修正,那又是一件麻煩事,除非各位有什麼方法解決B這種註解發生的問題(見說明)。--114.46.243.55留言2016年6月9日 (四) 05:53 (UTC)[回复]

你自己做測試都做錯了,怎麼A完全沒有使用name? A的誤植效果是這樣[6],所以A也會發生B的情況。--113.52.81.116留言2016年6月9日 (四) 07:06 (UTC)[回复]
照你這樣說,我拿A的做法去使用B,你能否解釋為什麼會變成這樣[7]?你都不懂我測試什麼,還指正我做錯,請你先好好瞭解A的測試結果,如果你不懂可以問,而不是照你的測試反批我錯,我測試不是像你專門找每個註解設計上瑕疵去測試,你這種測試方法再怎麼測都會使每個註解是無法使用,也難怪你測試結果會出錯。--114.46.233.82留言2016年6月9日 (四) 08:32 (UTC)[回复]
拿A的做法去B是這樣[8]才對啊,A的做法本身都沒name,拿去B你卻多了name出來,當然是錯了。--113.52.66.73留言2016年6月9日 (四) 09:09 (UTC)[回复]
明明是你自己去對<ref group="註">改成<ref group="註" name="註1">,這關我什麼事?我有叫你把B套在A去使用註解嗎?你自己測試方法錯了,還怪我!我是正常條件與正當使用下去做測試,並不像你這樣為了反駁我而反駁所做出的測試,刻意從不合理去找出能反駁之處對我指正說我錯,顯然這是你的問題。此外提醒你,之前我有說:「你先好好瞭解,如果你不懂可以問」建議,可是顯然你並沒採納建議,你依然故我,那麼我告訴你這次測試不是在於驗證A設計瑕疵,如果你是想趁我拿A與B對照時來反駁我的測試有錯,那你就繼續對我說我錯吧!因為再說下去,看樣子也只是吵起來,畢竟這不是我問題。--114.46.245.152留言2016年6月9日 (四) 13:12 (UTC)[回复]
看不懂,{{efn|name="注"|內容}}實際上是相當於「<ref name="注" group=lower-alpha>內容</ref>」,把每個efn的name都寫一樣本來就是錯誤寫法,跟這模板無關。efn的參數name就跟ref的參數name是一樣的,而group參數則跟ref的group參數一樣,只是預設是lower-alpha。不懂為何要以efn的name參數去比較ref的group參數--Liaon98 我是廢物 2016年6月9日 (四) 08:37 (UTC)[回复]
我這次的測試是反映出<ref group="註">與{{efn|name=注|}}使用時,從效果上看到差異,當有多個註解要去使用<ref group="註">時,每一個註解都可以使用相同的<ref group="註">,但是用在{{efn|name=注|}}時,必須得用{{efn|name=注1|}}、{{efn|name=注2|}}……{{efn|name=注100|}}這樣子下去,才能區分出每個註解,否則B比照A去使用,改成{{efn|name=注|}}就一定會出錯的,這事若發生在條目裡註解,萬一有人不小心將B的「name=注」參數用錯,以麥理浩為例:結果是這樣,要從中查出哪裡「name=注」參數出錯,可是很傷眼睛,因為B這種註解是被設計成「name=注」參數必要設定,當「name=注∑」參數裡∑值填錯,要修正會很難,這是正常顯示;反觀<ref group="註">是因為「註」值不用改,多個註解使用也依然可以將每一個註解有獨立而區分([9] 測試結果]可知,即使誤植也能將註解區分),這種優點就優於B註解方式,除非像113.52.66.73刻意去改成「group="註" name="註1"」,因為<ref group="註">要對應<references group="註"/>才能正常顯示,若是像我要按照113.52.66.73測試,將<ref group="註">改成<ref group="註1">使用是結果會出錯,這種是叫人為刻意的非正常使用,與{{efn|name=注∑|}}一定要對照上一個∑與下一個∑去設定的情況是不同,所以並非<ref group="註">設計問題,顯然可知使用A這種註解是沒有像B這種結果出錯。--114.46.245.152留言2016年6月9日 (四) 13:36 (UTC)[回复]
(~)補充:A測試結果[10]所謂「誤植」,請看裡面的原始碼,多個註解一起使用時,同時有二個相同註解,這效果反映出不用對<ref group="註">修改「註」值,也能區分出每個獨立註解,反觀{{efn|name=注∑|}}一定要修改「∑」值去對每個註解前後順序填上對應的值,{{efn|name=注1|}}……{{efn|name=注100|}}中間若是填錯,「∑」值有跳過號碼,就會發生有二個重號,後面的註解排序就會跟著出錯。--114.46.245.152留言2016年6月9日 (四) 13:51 (UTC)[回复]
你到底有沒有看到我說的「不懂為何要以efn的name參數去比較ref的group參數」?你上面的回文,還是在拿ref的group參數跟efn的name參數比較。我上面已經回你的,ref的name就是efn的name,ref的group就是efn的group,efn只是打包過的ref!!你的<ref group="註">是相當於「{{efn|group=註}}」,不是相當於「{{efn|name=註}}」!!!那麼「{{efn|name=註}}」相當於什麼?相當於「<ref name="註">」,懂了嗎??不論efn還是ref,name都不能定義多次,並不是efn不能定義多次有瑕疵!而就像是ref沒定義name的測是一樣,efn一樣可以讓name留白。--Liaon98 我是廢物 2016年6月10日 (五) 03:43 (UTC)[回复]
你好像連efn的name怎樣用都沒搞清楚,誰說B的name="注"是必要設定?[11],沒有了name十分正常。--113.52.66.73留言2016年6月9日 (四) 13:54 (UTC)[回复]

purge的翻译是在哪里提供的?

purge可以翻译成-{zh-hans:刷新缓存;zh-hant:清除快取;}-(参见:{{Purge}}),然而{{Documentation}}却翻译成了“清除”。这个的翻译是在哪儿提供的,谁帮忙找下谢谢。代码似乎是{{int:Code-rev-purge-link}},是在哪个专门负责I18N的Wikimedia项目中的?记不得找不到了。--Tomchen1989留言2016年6月10日 (五) 01:54 (UTC)[回复]

“1.66米(5尺5寸)(166 cm)”

AAA
身高1.66米(5英尺5英寸)
体重57公斤(126磅)

这是怎么回事?在{{infobox person}}里填入“{{convert|1.66|m|cm|abbr=on}}”就会显示成“1.66米(5尺5寸)(166 cm)”但我在其他地方打出“{{convert|1.66|m|cm|abbr=on}}”,显示正常,是“1.66米(166 cm)”。体重方面没出这样的问题。

经查,个人认为问题应该出在Template:infobox person/core里的“{{#if:{{{height_m|{{{height_cm|}}}}}}{{{height_ft|}}}{{{height_in|}}} | {{convinfobox|{{{height_m|{{{height_cm|}}}}}}|{{#if:{{{height_m|}}}|米|厘米}}|{{{height_ft|}}}|英尺|{{{height_in|}}}|英寸}} }}{{#if:{{{height|}}} | {{infobox person/height|{{{height|}}}}}}}”代码,希望能进行修正。--№.N留言2016年6月10日 (五) 02:11 (UTC)[回复]

{{infobox person}}的文档上建议你使用{{height}},如|height={{height|m=1.66}}(或者|height={{convert|1.66|m}}也可)放在{{infobox person}}中就显示为“1.66米(5英尺5英寸)”,这样正常了吧?还是说,你就是不想让它显示英制?--Tomchen1989留言2016年6月10日 (五) 02:34 (UTC)[回复]
不是我不想让它显示英制,可能我应该这么解释:在infobox person的height参数里填上“{{convert|1.66|m|ftin|abbr=on}}”,就会显示成“1.66米(5尺5寸)(5尺5寸)”,出现两个“(5尺5寸)”,看着也不舒服啊,况且在weight参数里输入“{{convert|57|kg|lb|abbr=on}}”时的显示效果和“{{convert|57|kg|abbr=on}}”是一样的,也就是说都会显示成“57千克(126磅)”而不是“57千克(126磅)(126磅)”,另外输入“{{convert|57|kg|st|abbr=on}}”的显示效果是“57千克(9.0 st)”,而不是“57千克(126磅)(9.0 st)”。--№.N留言2016年6月10日 (五) 03:23 (UTC)[回复]
@Naughty Jeffrey这模板是你改的,还是请你解决一下问题吧。--№.N留言2016年6月12日 (日) 04:38 (UTC)[回复]

倒是“英尺”不应该简写成“尺”…… --达师 - 334 - 554 2016年6月10日 (五) 14:01 (UTC)[回复]

可以写成“呎”和“吋”吧。--Kuailong 2016年6月10日 (五) 20:05 (UTC)[回复]
我觉得比起“英尺”应不应该写成“尺”,我所提出的问题更应该解决。--№.N留言2016年6月12日 (日) 01:45 (UTC)[回复]

终于找到真正的原因了!如果输入:

{{infobox person/height/switch
|{{convert|1.66|m|ftin|abbr=on}}
|{{#invoke:String|replace|{{convert|1.66|m|ftin|abbr=on}}| | }}
|m={{#invoke:String|find|{{#invoke:String|replace|{{convert|1.66|m|ftin|abbr=on}}| | }}|米}}
|c={{#invoke:String|find|{{#invoke:String|replace|{{convert|1.66|m|ftin|abbr=on}}| | }}|厘米}}
|f={{#invoke:String|find|{{#invoke:String|replace|{{convert|1.66|m|ftin|abbr=on}}| | }}|尺}}
|i={{#invoke:String|find|{{#invoke:String|replace|{{convert|1.66|m|ftin|abbr=on}}| | }}|寸}}
}}

的话,就会显示正常,即“1.66米(5尺5寸)”,但若是输入:

{{infobox person/height/switch
|{{convert|1.66|m|ftin|abbr=on}}
|{{#invoke:String|replace|{{convert|1.66|m|ftin|abbr=on}}| | }}
|m={{#invoke:String|find|{{#invoke:String|replace|{{convert|1.66|m|ftin|abbr=on}}| | }}|米}}
|c={{#invoke:String|find|{{#invoke:String|replace|{{convert|1.66|m|ftin|abbr=on}}| | }}|厘米}}
|f={{#invoke:String|find|{{#invoke:String|replace|{{convert|1.66|m|ftin|abbr=on}}| | }}|英尺}}
|i={{#invoke:String|find|{{#invoke:String|replace|{{convert|1.66|m|ftin|abbr=on}}| | }}|英寸}}
}}

的话,就会显示“1.66米(5尺5寸)(5尺5寸)”,看来原因就是因为把“英尺”简写成“尺”才导致显示不正常!不过我是希望abbr参数无论是显示成on还是off都能正常显示,至于技术上怎么实现我还不清楚。--№.N留言2016年6月12日 (日) 10:27 (UTC)[回复]

这个模板是从enwiki抄的,所以如果不重写的话,某种程度上只能配合原有逻辑:无论abbr=on还是off,在infobox里都会被处理成abbr=on的形式显示[12],这是通过Template:Infobox person/height完成的,而这里只列举了英文单位名。由于上面对如何缩写存在争议,建议先确定单位名后(包括全称和简称,两者也可以一样)再改infobox的这些问题。Liangent留言 2016年6月14日 (二) 03:09 (UTC)[回复]
不过奇怪的是为什么身高写在infobox上有问题,但体重却没一点问题,体重的{{Infobox person/weight}}、{{Infobox person/weight/locate}}和{{Infobox person/weight/switch}}的格式和身高的对应模板格式是类似的。--№.N留言2016年6月15日 (三) 00:59 (UTC)[回复]
因为在{{convert}}的输出里,体重的“公斤”实际上是“-{zh:公斤;zh-cn:千克;zh-tw:公斤;zh-hk:公斤;}-”,在Template:Infobox person/weight/locate里面两个数据都locate不到,所以就原样输出了。身高的“米”能找到但“英尺”找不到,于是就额外补上一个英尺……Liangent留言 2016年6月18日 (六) 05:43 (UTC)[回复]

2016年欧洲足球锦标赛条目标题繁简问题

2016年歐洲足球錦標賽” → “2016年欧洲足球锦标赛”:条目目前标题是繁体的“2016年歐洲足球錦標賽”,这个技术上很有问题啊:不管是模块:CGroup/Football,还是目前版本的条目开头的{{noteTA}}中,都显示,大陆简体用法是:欧洲足球锦标赛;台灣繁(正)體用法是:歐洲國家盃;香港(澳门)繁體用法也是:歐洲國家盃。所以,要不就用简体的“欧洲足球锦标赛”要不就用繁体的“歐洲國家盃”,否则技术上繁简转化有问题,而且用繁体时也根本不应该这样称呼。大家看看是不是这样。我无法移动,哪位管理员来移动一下?谢谢。(讨论原发Talk:2016年歐洲足球錦標賽#标题繁简问题--Tomchen1989留言2016年6月10日 (五) 19:37 (UTC)[回复]

WP:移动请求--Kuailong 2016年6月10日 (五) 20:17 (UTC)[回复]
唉,真没办法。。我是考虑到这个条目在接下来的这一个月内浏览数显然会很高,走WP:移动请求程序的话要挂个移动模板在条目开头,难看,而这个程序通常又很慢,搞不好移动模板要挂一个月,等大赛结束,移动讨论才出结果。哈哈。。。。我认为这属于繁简混用,我记得标题繁简混用的情况下,是要移动到不混用的标题的,但没找到能够具体定义“繁简混用”并讲清怎么做的规则(繁简转化的相关规则也够乱的,比如上面#純簡繁重定向有必要么?就是目前根本没有制定规则统一解决、可建可不建、可删可不删的一个东西)。总之,这应该算是个和繁简转化有关的技术性的问题,技术上,这就是个错误的、不该存在的标题。如果是这样的话,那么移动是没什么争议的,那么哪个管理员来执行一下移动就可以了。--Tomchen1989留言2016年6月11日 (六) 18:54 (UTC)[回复]
賽事創辦時名稱為歐洲國家盃(European Nations Cup;簡稱歐國盃),其後於1968年改名為現名歐洲足球錦標賽(European Football Championship),只是臺灣CNA等媒體或相關單位仍沿用舊中文名稱而已。--111.250.21.35留言2016年6月16日 (四) 04:26 (UTC)[回复]

修復音界號顯示

有一個很古老的問題,相信多維基人都知道,維基百科的音界號會顯示成這樣「·」,但其實這樣真的閱讀起來很不舒服,只有在沒有WikiEd時的原始碼編輯介面才會正常。

請問是否能調整音界號的顯示,改為全形符號?--Koala0090留言2016年6月12日 (日) 03:02 (UTC)[回复]

恐怕這個問題不是維基百科能夠解決。現時頁面內容的字體是無襯線體(font-family: sans-serif),而實際上每部電腦用哪一款字型(font)卻視乎瀏覽器設定及電腦上所安裝的字型來決定。但是那些中文字體要用半形顯示音界號的話,維基百科也沒有辦法。至於原始碼編輯介面,字體是等寬字體(font-family: monospace),這是方便看清楚程式碼的字體,可是卻不美觀。要是把頁面內容都改為無襯線體,對外觀影響甚大。--Quest for Truth留言2016年6月17日 (五) 00:21 (UTC)[回复]

2016年6月13日 (一) 18:41 (UTC)

提刪模版今天不能正常運作

麻煩那位檢查一下:

{{subst:DRItem| Type=fame
 | DRarticles =  |  |  |  |  |  |  | }—~~~~<br />

--Nivekin請留言 2016年6月16日 (四) 02:42 (UTC)[回复]

@Nivekin閣下少了這個},以至於模板無法展開。--★Fish out Yue in the water.☆ 2016年6月16日 (四) 02:54 (UTC)[回复]