維基百科:互助客棧/技術/存檔/2017年8月

模塊:CGroup/IT不工作

於Phabricator內跟蹤
任務T104109

今天發現模塊:CGroup/IT好像不工作了。不知道問題出在什麼地方？查了一下歷史版本，似乎在此版本之後，該模塊頁面代碼部分的的語法高亮就失效了（但編輯模式下的語法高亮還是正常的）。懷疑可能是lua語法錯誤（或繁簡轉換語法錯誤）導致模塊不工作，但是實在找不出來哪裡有語法錯誤（一個猜測，可能藏有不可見字符導致？），當然也可能不是語法錯誤，而是其它問題....--百無一用是書生 (☎) 2017年8月2日 (三) 02:30 (UTC)

目前轉換正常了（看來是臨時故障），但是這個語法不高亮還是如故--百無一用是書生 (☎) 2017年8月2日 (三) 03:22 (UTC)

我要怎樣才能將兩個完全一樣的東西合併

• 以下都是中國國家奧林匹克足球隊連結
  • https://www.wikidata.org/wiki/Q987926#sitelinks-wikipedia
  • https://www.wikidata.org/wiki/Q23892237#sitelinks-wikipedia
• 以下都是帕拉林匹克運動會獎牌統計連結
  • https://www.wikidata.org/wiki/Q15922124#sitelinks-wikipedia
  • https://www.wikidata.org/wiki/Q2299775#sitelinks-wikipedia

請說要怎麼樣。

Simon 1996（留言） 2017年8月2日 (三) 23:31 (UTC)

• @Simon 1996：不是已經合併了嗎？--A2093064#Talk 2017年8月3日 (四) 00:11 (UTC)

帶參數的「內鏈」問題

鏈接帶參數是不是不能用內鍊表示，而必須用<span class="plainlinks">[{{fullurl:某|参数}} 文字]</span>這樣的方法？這樣的方法在維基百科已經十分廣泛使用，但產生的鏈接會與真正的內鏈有區別，例如顏色，此外內鏈能夠自動生成鼠標懸浮時的文字而這樣的鏈接不行。之前弄過{{fullurl}}模板但由於易出故障而高風險就被還原了。Minecraft Wiki會利用css自動識別外鏈形式的內鏈並移去鏈接的箭頭，且Minecraft Wiki將所有的外鏈都改成了內鏈的顏色。（我也製作過Fullurl模塊。）

不過，就真的不能直接製造出像某些特殊頁面中的帶有參數的內鏈嗎？能否使用[[xxx|action=edit]]這樣的形式。？--SolidBlock^留言 2017年8月7日 (一) 08:50 (UTC)

和這個phab:T25225有點像--百無一用是書生 (☎) 2017年8月8日 (二) 12:39 (UTC)

Tech News: 2017-32

最新技術新聞來自維基媒體技術社群。請將這些變化轉告其他用戶。不是所有的變化都將影響您。翻譯亦已提供。

最近更新

• 您可以查看在特定國家內的人喜歡閱讀哪種維基百科語言版本。此工具稱作Wikipedia Views Visualized。 [1]
• 架構委員會現已改稱維基媒體技術委員會。您可以閱讀新章程。 [2]

問題

• 當有人編輯您監視列表上的頁面時，您可以獲得電子郵件通知。您可以選擇不接收小編輯的電子郵件。而目前這一功能存在問題，這導致有時有人在某一小編輯後作出了常規編輯，但您仍未接收電子郵件。開發人員正在修復該問題。直到此問題修復之前，您可以在您的參數設置中，在「用戶資料」底部激活「當我的監視列表中的頁面和文件有小編輯時也發送電子郵件通知我」。 [3]
• 感謝按鈕有時對移動用戶不工作。這是因為新的錯誤影響，現已修復。 [4]

本周晚些時候的更新

• MediaWiki的新版本將於8月8日部署於測試維基及MediaWiki.org。它將於8月9日部署至非維基百科wiki及部分維基百科，並於8月10日部署至所有wiki，參見日曆。

將來更新

• 仍在Windows XP（以下簡稱XP）上使用Internet Explorer 8（以下簡稱IE8）的編輯者和閱讀者將無法使用維基百科。XP上的IE8不能安全地連接wiki。當我們允許他們連接時，這意味着我們無法為其他人提供足夠安全保障。如果您在XP上使用IE8的話，您可以安裝並改用火狐（Firefox）52 ESR。大約0.1%的維基媒體wiki訪問流量來自XP上的IE8用戶。 [5]
• 維基百科鏈至章節的鏈接在不使用拉丁字母的語言中不能工作。您的瀏覽器地址欄中URL會顯示拉丁字符（例如.D0.A1.D1.81.D1.8B.D0.BB.D0.BA.D0.B8）而不是wiki語言的章節標題。將來這些鏈接將改為對應wiki的文字。這將在接下來幾個月解決。 [6][7]
• 瀏覽器「打印」功能打印的Wiki頁面將擁有更新樣式。新樣式將會像您下載為PDF時那樣。這將更好顯示表格、信息框和標題。 [8][9]

技術新聞由技術新聞編者準備，並由機器人送達 • 貢獻 • 翻譯 • 獲取幫助 • 提供反饋 • 訂閱或退訂。

2017年8月7日 (一) 21:45 (UTC)

跟XP說再見為何不徹底點呢^{[開玩笑的]}--Liuxinyu970226（留言） 2017年8月7日 (一) 22:36 (UTC)

另外我真是看不懂@Shizhao：在phab:T172379說了些什麼。--Liuxinyu970226（留言） 2017年8月9日 (三) 09:03 (UTC)

我的意思是為什麼三個來源，只有其中一個來源的數據不一樣（在只計算用戶訪問數據的情況下），而如果feeds數據做了額外的處理，清理掉了更多的bot數據，那麼就意味着最近一個月來訪問量第一的wiki頁面，第二的維基媒體基金會頁面，其每天大多數的的訪問量（數萬計）都是來自於bot，這未免太奇怪了一點（而且pageview api 竟然還完全沒有識別出這麼多的bot流量）--百無一用是書生 (☎) 2017年8月9日 (三) 11:44 (UTC)

落實存檔頁保護

我看這幾天方針人挺多的，特地來重提以前的討論。

上回討論

前期討論

本人提議在Wikipedia:保護方針#臨時保護的條件最下方增加下列句子：

• 對已確定將會在首頁展示的文章／頁面中進行半保護，直至文章／頁面已經在首頁展示完畢

並且更改下面句子：

• 對條目任何討論的歸存檔，只允許作為歷史記錄來查看。

以上，--1233|^聯繫我 2017年3月13日 (一) 09:10 (UTC)

(？)疑問1.是否有明確的證據可以證明在首頁展示的條目和圖片是高風險頁面。2.對於現有的條款「對條目討論的歸檔，只允許作為歷史記錄來查看。」我有點疑惑，按照這所述這不就是屬於永久保護了嗎。——꧁༺星耀晨曦༻꧂（留言） 2017年3月13日 (一) 09:27 (UTC)

(：)回應1.保護頁面不受破壞而已，已註冊用戶仍然可以編輯。2.我也想知道。--1233|^聯繫我 2017年3月13日 (一) 10:24 (UTC)

罕見的(－)反對：形同大舉「預防性保護」。－ 執行編輯 Aotfs2013 留於 2017年3月14日 (二) 16:12 (UTC)

有保護不是預防性質的嗎？就算高風險，也是經過評估之後，加上去的原因。其本質無異於恐怕受到破壞。而普通保護亦是預防進一步受破壞。所以結論是沒有保護不是預防性質。--J.Wong 2017年3月15日 (三) 04:24 (UTC)

存檔全保護亦無妨，終歸無修改需要。不過這得端看每個討論存檔安排，譬如互助客棧方針區是一月一檔，那最近一個月就應該暫時不保護，以便存檔。但之前的存檔，保護則可以大大減省維護成本，亦明顯無編輯需要。--J.Wong 2017年3月15日 (三) 05:12 (UTC)

對於第一個提案，WP:保護方針#臨時保護下面已經有了「重要注釋：如果一個條目很活躍，可能是由於該條目在首頁上有鏈接，或者是因為從外站有顯著的鏈接，這種情況下該條目就很可能成為破壞的目標。一般在此情況下，不需對頁面實施保護，但最好將這些條目加到監視列表中，這樣自己對破壞可以及時恢復。」保護在首頁展示的條目與維基百科的精神相斥。因為這將會阻擋大量的有益編輯，即使考慮到高可見性帶來的破壞隱患，我相信我們的維基人會第一時間應對破壞。——꧁༺星耀晨曦༻꧂（留言） 2017年3月15日 (三) 09:38 (UTC)

讓我們看看前天在英文維基百科展示的God of War II。這個頁面在大前天的時候，每天的瀏覽量不足1000，然而在登上首頁後一瞬間就有了3萬瀏覽量[10]。然而那時候這個條目只執行了移動全保護（首頁的連鎖保護）。相比之下，我們中文維基百科在13日展示的國立故宮博物院有4000+瀏覽量[11]。可以相信，我們沒必要全保護在首頁展示的條目。——꧁༺星耀晨曦༻꧂（留言） 2017年3月15日 (三) 10:07 (UTC)

從上列數字看來的確無太大需要。存檔呢？--J.Wong 2017年3月15日 (三) 10:43 (UTC)

我對第二項提案，把條目改成任何沒有反對意見。但是，我對目前這項條款（保護存檔頁）抱有疑惑。從WP:保護方針的精神來看，「除非是高風險頁面，否則保護只能用於那些已經被嚴重破壞的頁面等其它情況（其它情況指:全保護被永久封禁用戶的用戶頁、已去世維基人的用戶頁..）」，存檔頁沒必要保護。然而從實際應用和反破壞的角度來看，萬一存檔被破壞者利用了，比如鬼祟破壞（惡意修改存檔的他人留言，扭曲他人試圖表達的觀點），鬼祟破壞的特點使得閱覽存檔頁的讀者不會刻意去查看存檔頁的編輯歷史，使讀者可能會看到與以前討論的內容不相符的觀點。由於沒有先例，我暫時沒辦法得出「保護存檔」和「不保護存檔」哪個更對維基百科好。不過拋開精神不管，保護存檔對防止破壞來說無疑是有益的。——꧁༺星耀晨曦༻꧂（留言） 2017年3月15日 (三) 11:45 (UTC)

綜合維基上各項規則來看，人人可以編輯顯然應該只適用於主名字空間、討論空間及維基百科空間下各個討論區。模板空間，高風險模板保護奉行已久。介面，如Mediawiki，及編碼，如js、css，則僅有原作者或管理員級別以上用戶始可編輯。用戶頁，用戶頁指引明言未得同意，不得編輯他人用戶頁。--J.Wong 2017年3月15日 (三) 13:43 (UTC)

我希望藉此機會來明確存檔保護的性質（全/半、編輯保護/移動保護、臨時/永久）。——꧁༺星耀晨曦༻꧂（留言） 2017年3月15日 (三) 16:45 (UTC)

個人建議全保護，永久，編輯保護。不過這個設定可能有爭議，半保護亦無不可。另外，數量不鮮，除非abot願意承包處理，否則作為可申請項目處理，即有人申請就可以作這種保護，管理員遇到亦可自行保護。--J.Wong 2017年3月16日 (四) 04:22 (UTC)

初步贊成，但應想到如何執行。本項涉及大量頁面。--Temp3600（留言） 2017年3月15日 (三) 08:22 (UTC)

結論:容許對存檔頁面設置永久全/半保護。--Temp3600（留言） 2017年3月18日 (六) 10:42 (UTC)

我個人較贊成半保護，因全保護可能爭議過大。--Temp3600（留言） 2017年3月18日 (六) 10:42 (UTC)

第二階段討論

提案：修改WP:保護方針有關存檔頁保護的條款

當下，保護方針對存檔頁保護的定位是臨時保護。然而這個條款處於「臨時保護」這個定位有點奇怪，如果是因為破壞而保護的話，則和臨時保護章節下的第二條差不多。如果是為了防止鬼祟破壞而保護的話則應該屬於「永久保護」的範疇。因此，我提議把這條移到上面的永久保護章節去。——꧁༺星耀晨曦༻꧂（留言） 2017年3月16日 (四) 06:42 (UTC)

• 議案相類，合併討論。--J.Wong 2017年3月17日 (五) 07:46 (UTC)

(－)反對：全保護「不是用來預防可能會發生的破壞」--Maccomcre（留言） 2017年3月18日 (六) 00:51 (UTC)

@Maccomcre：那麼閣下是認為應該把現有條款刪除？因為現有的對存檔頁的條款和「若頁面或圖片近期被封禁用戶進行頑固破壞或頑固編輯，則實施保護」的性質一樣。都是用來防止破壞者進一步破壞的。——꧁༺星耀晨曦༻꧂（留言） 2017年3月18日 (六) 02:30 (UTC)

感覺坡滑大了。「預防可能事件」否決的更接近是憑據較少，帶「水晶球」性質的保護；被近期頑固反覆破壞、編輯的個別頁面矛頭對得則很清楚。——Artoria2e5_編 保持討論完整，直接{{ping}}我回復。 2017年3月18日 (六) 03:54 (UTC)

那首頁、高風險模板、Mediawiki介面、css及js編碼及他人用戶頁呢？為何這些保護又不是「不是用來預防可能會發生的破壞」？又不是「憑據較少」？的而且確，維基百科是開放予眾人編輯的，不過應該是局限於主名字空間、分類、幫助、普通較少連接的模板、維基百科內各空間下的討論區等空間，但必須承認維基百科內有部分空間是要限制用戶編輯。以減低維護成本。存檔的而且確，僅供參閱已經可以，並毋須亦不應修改。維基百科存檔眾多，閣下肯定有鬼祟破壞時，可以有人第一時間發現？--J.Wong 2017年3月18日 (六) 05:06 (UTC)

「除非被保護頁面是高風險頁面」，條款的原本意思是低風險頁面不需要預防，而存檔是不常查看的頁面，低風險，所以存檔應該被嚴重破壞才能全保護。--Maccomcre（留言） 2017年3月18日 (六) 08:20 (UTC)

存檔並非不常查看，在查找過去的討論時往往要找存檔。由於大多數存檔頁（比如:WP:VIP和互助客棧的存檔）都是由機器人自動生成的，幾乎沒啥人監視。我認為，此類頁面擁有中等可見度、低破壞幾率、低反破壞效率、無需編輯的性質。論一個頁面是否是高風險頁面不僅僅是看這個頁面是否是容易被破壞，而是要結合反破壞效率一起看。根據存檔頁極低的監視率，一旦受到鬼祟破壞（明顯的破壞很可能會被最近更改巡查回退）則難以被發現。由於具有中等的可見度，不能保證閱覽者里沒有高級破壞者。並且，此類頁面一般無需修改。而且，管理員也沒有那麼多精力盯着Special:未受監視頁面看。綜合以上所述，「無需編輯」的性質和維基百科的精神「人人皆可編輯」不衝突，加上此類頁面是高風險頁面（低反破壞效率並具有極高的信任度），我覺得應該實行保護。——꧁༺星耀晨曦༻꧂（留言） 2017年3月18日 (六) 09:27 (UTC)

始終不太同意，可見度比條目低，說是高風險都太過分，查看存檔時自然也要先查看歷史，查看歷史自然便會找到鬼祟破壞。查看存檔不事先查看歷史是用的習慣有問題。--Maccomcre（留言） 2017年3月22日 (三) 00:18 (UTC)

有誰看任何一個頁面都會去看編輯歷史的？看一個頁面的同時看編輯歷史應該只是個別人的習慣。雖然這是一個好習慣，但你不能保證每個人都會去看編輯歷史。同樣，閣下也不能保證每個查存檔的人都能發現鬼祟破壞。這就是為什麼我認為存檔頁是「高風險」。——꧁༺星耀晨曦༻꧂（留言） 2017年3月22日 (三) 00:58 (UTC)

贊成保護。我同時贊成J.WONG的說法:"開放予眾人編輯"的部分只限於那些編輯可以為維基帶來好處的部分。編輯存檔絕少對維基有好處。--Temp3600（留言） 2017年3月18日 (六) 10:46 (UTC)

===結案及公示===

1. 容許對存檔頁面設置永久半保護。

現公示七日。如無異議，即行修改。--Temp3600（留言） 2017年3月19日 (日) 10:10 (UTC)

• (－)反對，只是討論了不夠一星期便結案？太快了，而且討論人數都少，中間還有人反對，根本不能當作有初步共識。--Maccomcre（留言） 2017年3月19日 (日) 11:48 (UTC)
  • @Maccomcre：那麼，閣下覺得我上面說的話怎麼樣。——꧁༺星耀晨曦༻꧂（留言） 2017年3月21日 (二) 06:46 (UTC)
• 的確，過於倉猝，如果收窄範圍至某幾類存檔或者只是經管理員評估過後覺得需要保護才施行永久全保護，又如何呢？--J.Wong 2017年3月19日 (日) 12:42 (UTC)
  • 用戶討論頁的存檔是否需要保護由該用戶確認吧。——꧁༺星耀晨曦༻꧂（留言） 2017年3月19日 (日) 14:09 (UTC)
• 一位IP用戶修改他人留言的編輯已被撤銷。—john doe 120（talk） 2017年3月19日 (日) 15:11 (UTC)
• (－)反對，沒必要這麼做。除非存檔頁面被破壞多次，通常管理員會視情況實施保護。--小躍（撈出記錄） 2017年3月22日 (三) 01:12 (UTC)
  • 閣下認為會有用戶察覺到破壞？我覺得，除非有人盯着最近更改看，一個存檔頁被破壞者刪了80%的破壞都沒人會發現。——꧁༺星耀晨曦༻꧂（留言） 2017年3月22日 (三) 01:45 (UTC)
• 半保護會是一個可行方案。--1233|^聯繫我 2017年3月22日 (三) 06:57 (UTC)
• 討論頁存檔的話我覺得全保護也沒什麼，本來就不需要編輯的地方。--淺藍雪^❉ 2017年3月22日 (三) 15:47 (UTC)
• 我覺得還是容許永久半保護吧。全保護overkill。雖然現在想不到，但是如果真的出現需要編輯的情況，難道搞EP不成，現在EP處理比蝸牛還慢。Bluedeck 2017年3月25日 (六) 04:55 (UTC)
• 我想搞清楚，「臨時保護」章節下的存檔頁是個什麼情況。要不就是去掉這個條款（臨時保護存檔頁本來就不應該出現在這裡），要不就移動到「永久保護」章節。——꧁༺星耀晨曦༻꧂（留言） 2017年3月25日 (六) 10:06 (UTC)
• 應該移去永久保護。--J.Wong 2017年3月27日 (一) 03:49 (UTC)
• (＆)建議如果加個過濾器，用戶編輯討論存檔頁時予以標籤，會否較省事？--578985s（留言） 2017年3月30日 (四) 15:49 (UTC)
  • 不省事吧。因為這得讓人定期查看濫用日誌。如果採用保護的方式，則可以利用機器人自動對存檔進行保護。——꧁༺星耀晨曦༻꧂（留言） 2017年3月30日 (四) 16:29 (UTC)
  • 也是可以設立過濾器來收集數據，若然未能取得共識改修改方針，則此亦是可行之策。由其若然最後只設為半保護，則其實兩者並行不悖。--J.Wong 2017年4月2日 (日) 01:04 (UTC)

小結

根據上面的討論情況，有兩位反對者，但也有一些支持意見。作為支持把「存檔頁保護」移動到「永久保護」的我來說，我有兩個提案：

1. 把「存檔頁保護」移動到「永久保護」章節
2. 把「存檔頁保護」定性為「半保護」（提案2的前提是提案1）

我認為「存檔頁保護」在「臨時保護」章節里就是一個錯誤，要不就移到「永久保護」要不就從WP:保護方針移除。不知道大家意見怎麼樣？並通知兩位反對者user:小躍user:Maccomcre[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]——꧁༺星耀晨曦༻꧂（留言） 2017年3月28日 (二) 12:42 (UTC)

額，所以說，冷了？可以考慮公告一周無人反對就實施了？——꧁༺星耀晨曦༻꧂（留言） 2017年4月4日 (二) 07:45 (UTC)

就如此吧。--Temp3600（留言） 2017年4月4日 (二) 11:52 (UTC)

• 已開始公告。若一周後無人對上述提案提出反對意見，則移動具體條文到「永久保護」，並開啟後續討論（如何實施）。——꧁༺星耀晨曦༻꧂（留言） 2017年4月9日 (日) 16:07 (UTC)
• 贊成永久半保護。user:小躍user:Maccomcre[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]Bluedeck 2017年4月9日 (日) 21:29 (UTC)
• 若確實有需要，那永久半保護，是一個不錯的辦法。Wetrace歡迎參與人權專題 2017年4月27日 (四) 11:11 (UTC)

---

其實，我還想建議把用戶討論頁的存檔排除在外。或或者默認不保護用戶討論頁存檔，要讓用戶申請主動申請。——꧁༺星耀晨曦༻꧂（留言） 2017年4月10日 (一) 04:22 (UTC)

本提案可能與維基基金會政策有牴觸

根據維基媒體基金會針對於半保護的規定：「Semi-protection ... is not intended for pre-emptive protection of articles that might get vandalized」（半保護…不是用來預防可能會發生的破壞），如果我理解無錯的話，上面的提案應該是「即使存檔沒有破壞也可以半保護」，那麼在無破壞時對存檔實行半保護會違反上述規條，故即使上面提案有共識，基金會應該會行使WP:CONEXCEPT來阻止。這僅僅是我對於現在情況的理解，勞煩各位維基人（特別是行政員或以上權限的維基人user:Shizhaouser:Winguser:Kegnsuser:PhiLiPuser:Jimmy Xu[[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]][[user:]]）確認一下本提案的合法性，謝謝。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2017年4月10日 (一) 23:19 (UTC)

維基新聞的慣例是老新聞全保護--百無一用是書生 (☎) 2017年4月11日 (二) 02:25 (UTC)

個人見解，這個meta上的半保護頁面似乎並不屬於WP:CONEXCEPT所要求的基金會理事會公告。其次，半保護存檔頁面不太可能有實際危害到維基百科的風險，基金會不太可能出面阻止。--Wcam（留言） 2017年4月11日 (二) 02:48 (UTC)

如果基金會真的出面阻止的話，可以另外發新公告的嘛，所以仍有WP:CONEXCEPT的可能，當然出不出面阻止又是一回事了。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2017年4月11日 (二) 04:47 (UTC)

已經有太多先例證明維基百科之中，不是所有頁面都會開放予所有人編輯，包括「首頁」、高風險模板、介面、.css/.js及他人用戶頁。存檔頁明顯無任何編輯需要。還有別漏了「ARTICLES that might get vandalized」。WP:什麼是條目--J.Wong 2017年4月11日 (二) 03:27 (UTC)

所以我在想元維基所謂Article究竟是否等於我們的WP:什麼是條目，另外您舉的基本上都是全保護的例，不是半保護（除了用戶頁(但這個通常在破壞發生後才會施行)）。又或者換句話說，如果上面結論是採用「全保護」的話，則應該無牴觸；但採用「半保護」的話，則反而有牴觸（如果他們所謂的Article包括所有頁）。或者可否有熟悉基金會那邊的人幫忙詢問一下，免得他們真的出手阻止時場面會很尷尬。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2017年4月11日 (二) 04:47 (UTC)

半保護的高風險模版比全保護的多很多。 --碸中嘌呤的白磷_{萃取 打譜} 2017年4月11日 (二) 05:01 (UTC)

照上文下理推斷，很難相信articles並非條目，尤其下面加上「in english wikipedia」。--J.Wong 2017年4月11日 (二) 05:24 (UTC)

但是元維基上的政策頁面也是放在主名字空間的說……另已見元維基相關詢問已被提出，期待他們的答案。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2017年4月11日 (二) 06:54 (UTC)

該文二○○五年建立之後一直就無太大變化，一○年加入meta:Category:Wikimedia_policies_and_guidelines。但翻查紀錄，當年該用戶是在整理頁面分類，所以他同時亦將其他頁面加入相應分類。而到底此文有否經過討論呢，討論紀錄則遍尋不獲。難道未經過討論就可以成為全域方針？而真正全域方針亦似乎另有分類，正是meta:Category:Global_policies，內有各項全域方針正正影響着眾多計劃及規範着諸位參與者。--J.Wong 2017年4月12日 (三) 16:54 (UTC)

唯有等他們之後怎麼答覆吧，如果確認了該頁本身有問題，又或一週後都無人答覆的話，那就當本案沒有問題了。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2017年4月12日 (三) 21:46 (UTC)

• 元維基的一位管理員已回覆：m:Semi-protection頂多當論述來用。而且這位管理員還給這個提案提了一個建議(Re "pre-emptive")。——꧁༺星耀晨曦༻꧂（留言） 2017年4月13日 (四) 02:21 (UTC)
  • OK，那麼就當本案沒有與政策牴觸，可以繼續公示。（話說元維基在最後給的建議似乎在暗示不太希望我們為了預防破壞而進行半保護？）--街燈電箱150號 開箱維修 抄錶 檢驗證明 2017年4月13日 (四) 03:19 (UTC)
  • 他是在提議用過濾器解決，個人認為兩者都可行。現時個人傾向半保護加過濾器。--J.Wong 2017年4月13日 (四) 04:06 (UTC)
    • 如果採用半保護，那麼過濾器只用設置為標記標籤就可以了。——꧁༺星耀晨曦༻꧂（留言） 2017年4月13日 (四) 15:43 (UTC)

兩個方案

翻查紀錄，該項明顯是翻譯出錯，該句應該是指現時保護方針「歷史唯讀」，即保護臨時復還頁面以便進行存廢覆核討論，完全無關於討論頁存檔。在加上參考其他保護項目及上列討論以後，建議兩個方案︰一、存檔保護設為永久全保護，經評估或申請後實施，類似於高風險模板；二、使用編輯過濾器標籤編輯並提示用戶，如非必須，勿作編輯。--J.Wong 2017年4月11日 (二) 04:53 (UTC)

我個人認為半保護即可。而且我還認為除了個人用戶討論頁之外的討論頁不需要申請就可以實施保護。——꧁༺星耀晨曦༻꧂（留言） 2017年4月11日 (二) 05:24 (UTC)

• 當下是什麼情況(๑❛ᴗ❛๑^?)。現在已經證明存檔頁保護不會受到全域方針的影響。現在的分歧就在，保護的程度(全/半保護)。我個人是偏向半保護，並建議存檔頁保護默認不保護用戶討論頁存檔。——꧁༺星耀晨曦༻꧂（留言） 2017年4月16日 (日) 12:26 (UTC)
• 半保護加過濾器標籤。--J.Wong 2017年4月16日 (日) 12:31 (UTC)

---

目前的情況，無後續意見。那麼又公告一周。如果無反對意見，則認為以下條款：

1. 啟用「存檔頁保護」
2. 對除個人用戶討論頁存檔以外的存檔進行保護
3. 程度:半保護，保護時間:永久
4. 採用濫用過濾器來標籤編輯存檔的行為

具有社群共識。——꧁༺星耀晨曦༻꧂（留言） 2017年4月17日 (一) 03:21 (UTC)

樓上JWong君不是一直在說過濾器麼。 --碸中嘌呤的白磷_{萃取 打譜} 2017年4月17日 (一) 06:00 (UTC)

對對，過濾器。已添加。——꧁༺星耀晨曦༻꧂（留言） 2017年4月17日 (一) 08:50 (UTC)

共識形成

歷經多個月的討論後，此方案在多次確認下，得到社群的共識，因此，存檔頁保護成為方針的內容，將寫進WP:保護方針里。接下來就應該討論討論如何去保護中文維基百科裡大量的存檔。——꧁༺星耀晨曦༻꧂（留言） 2017年4月25日 (二) 15:13 (UTC)

已加入保護方針中。——꧁༺星耀晨曦༻꧂（留言） 2017年4月25日 (二) 15:35 (UTC)

後續討論:對User talk下的討論存檔的處理

我建議採用「默認不保護，需用戶主動申請」的形式。——꧁༺星耀晨曦༻꧂（留言） 2017年4月25日 (二) 15:33 (UTC)

同意。而互助客棧等的討論，則應以admin-bot批量保護。--Temp3600（留言） 2017年4月29日 (六) 16:31 (UTC)

可能需要技術猿。——꧁༺星耀晨曦༻꧂（留言） 2017年4月29日 (六) 20:13 (UTC)

• 咦。明明正值夏日，為什麼空氣那麼冷。——꧁༺星耀晨曦༻꧂（留言） 2017年5月9日 (二) 15:30 (UTC)
• 不如讓用戶自行選擇要不要保護。——Morgan Siu（對話｜貢獻） 2017年5月10日 (三) 06:03 (UTC)
• (＋)同意。若能不需申請，直接做成一個自動化的選項是最好的。例如在討論頁上放置一個模板，機器人偵測到此模板即自動保護等。—以上有簽名的留言由R96340（對話）於 加入。 2017年5月11日 (四) 04:30 (UTC)
  • 有沒有可能不用機械人，直接授權用戶自行保護用戶討論頁存檔，好像編輯提示（普通用戶可以編輯自己用戶頁的編輯提示，其他頁面則需要管理員才可以）——Morgan Siu（對話｜貢獻） 2017年5月11日 (四) 06:11 (UTC)
    • 那也可以設置一個過濾器，其中包含一份用戶討論頁存檔名單，只允許管理員和討論頁對應用戶編輯。想加入名單者可以去Wikipedia:防濫用過濾器/過濾器請求或者另開專頁申請。這樣的好處是討論頁存檔名稱有規律時，可以用正則表達式方便地匹配所有存檔頁。 --碸中嘌呤的白磷_{萃取 打譜} 2017年5月11日 (四) 07:22 (UTC)
      • 那就不如更進一步，授權用戶自行選擇要不要保護其用戶頁及其子頁面。——Morgan Siu（對話｜貢獻） 2017年5月12日 (五) 02:21 (UTC)
      • 此提議建議另開一段討論，因為上面未曾討論是否容許用戶自行保護其用戶頁及其子頁，而且牽涉到其他方針，包括《用戶頁方針》。--J.Wong 2017年5月12日 (五) 03:04 (UTC)

建議授權用戶自行保護及刪除自己的用戶頁及其子頁面（用戶對話頁除外）

這樣可以減輕管理員的工作量，反正用戶頁對其他人來說也沒有編輯需要。——Morgan Siu（對話｜貢獻） 2017年5月12日 (五) 06:08 (UTC)

把任何沒有移動保護的頁面移動到用戶頁後刪掉，用戶對話頁也可以刪了。--A2093064#Talk 2017年5月14日 (日) 13:27 (UTC)

@A2093064：對所有用戶對話頁實施移動保護。——Morgan Siu（對話｜貢獻） 2017年5月15日 (一) 06:11 (UTC)

@Morgan Siu：那麼所有條目也要移動保護嗎，還有有些人會用移動討論頁來進行存檔。--A2093064#Talk 2017年5月15日 (一) 06:35 (UTC)

@A2093064：只允許移動至用戶討論:Example/存檔，或必須到移動請求進行。——Morgan Siu（對話｜貢獻） 2017年5月15日 (一) 06:56 (UTC)

@Morgan Siu：那麼條目移動到用戶頁呢。--A2093064#Talk 2017年5月16日 (二) 00:43 (UTC)

@A2093064：禁止條目移至用戶頁。——Morgan Siu（對話｜貢獻） 2017年5月16日 (二) 03:31 (UTC)

@Morgan Siu：您的意思應該是要禁止非用戶空間移到用戶空間。那麼有時新加入的維基人偶爾會在主條目空間誤建用戶頁，這樣的話其他用戶就不能幫忙修正了。--A2093064#Talk 2017年5月16日 (二) 05:01 (UTC)

@A2093064：只是偶爾，可以到移動請求找管理員幫忙。——Morgan Siu（對話｜貢獻） 2017年5月16日 (二) 05:04 (UTC)

@Morgan Siu：新的問題，如果有人在用戶頁廣告又保護後，其他人就不能掛CSD G11了。--A2093064#Talk 2017年5月16日 (二) 05:07 (UTC)

@A2093064：不快速刪除，用頁面廢存討論。——Morgan Siu（對話｜貢獻） 2017年5月16日 (二) 05:09 (UTC)

@Morgan Siu：本來應該快速刪除的東西，為何要退而求其次存廢討論呢？--A2093064#Talk 2017年5月16日 (二) 05:10 (UTC)

@A2093064：保護用戶頁的好處比壞處多，就好像保護一個條目必定會阻止建設性編緝。——Morgan Siu（對話｜貢獻） 2017年5月16日 (二) 05:14 (UTC)

@Morgan Siu：看看Wikipedia:條目所有權#用戶頁。--A2093064#Talk 2017年5月16日 (二) 05:23 (UTC)

@A2093064：沒話可説，還原基本部：建議要申請才保護用戶討論頁存檔。——Morgan Siu（對話｜貢獻） 2017年5月16日 (二) 05:28 (UTC)

• 從編輯需求出發感覺可行。並建議禁止用戶保護具有討論性質的用戶頁(即使不是用戶討論頁)。不過這真的技術上做得到嗎？我傾向「個人親自去Wikipedia:請求保護頁面申請」。——꧁༺星耀晨曦༻꧂（留言） 2017年5月15日 (一) 07:16 (UTC)

(－)反對，PER A209306 提到的條目所有權。維基人有權利編輯全站頁面，甚至 MediaWiki 站點文本這些特殊內容有共識也可以修改。就算一般沒有理由編輯用戶頁面，也不應該加以限制。有針對一個用戶的破壞再批量臨時半保護也不遲。

• 條目所有權方針: 「用戶頁不是個人主頁，並非用戶所有」，「他們也有權編輯您的用戶空間的其他頁面」。
• 用戶頁指引: 「不過空間的所有權還是歸維基團體所有」，「其它用戶也可以編輯你的空間」。

Dargasea^{t ‧ c ‧ s} 2017年5月16日 (二) 05:34 (UTC)

那麼我也收回之前的建議。——Morgan Siu（對話｜貢獻） 2017年5月16日 (二) 05:46 (UTC)

後續討論:如何批量對除User和User talk以外的討論存檔進行保護

由於保護需要管理員權限，而且人工一個個保護太沒有效率了，我建議開發一個admin-bot出來，批量保護。——꧁༺星耀晨曦༻꧂（留言） 2017年5月15日 (一) 07:20 (UTC)

• 我的意思是授權，不用任何人幫忙。可以問一下維基技術人員，應該可行。除了用戶對話頁，還會有討論性質的用戶頁嗎？——Morgan Siu（對話｜貢獻） 2017年5月15日 (一) 10:10 (UTC)

上面是上回討論。簡而言之就是對除用戶討論名字空間(User talk:)下的存檔頁以外的討論頁面存檔頁進行永久半保護。此項已有社群共識，但沒有具體實施方案從而擱置。我想放在這裡，來看看有沒有技術大佬來實現這個共識。我覺得，可以開發一個管理員機器人來批量保護。——꧁༺星耀晨曦༻꧂（留言） 2017年8月9日 (三) 16:28 (UTC)

[[::頁面名]]不再能連到條目

請問最近有什麼變更使得 [[::頁面名]] 這樣的語法無法再連結到頁面呢，效果顯示為 頁面名 。我剛剛修復了一個長久以來正常的模板，但突然出現的錯誤，我相當懷疑是這個問題，我的編輯：1、2、3。--A2093064#Talk 2017年7月31日 (一) 13:57 (UTC)

[[::页面名]]不行，不過[[:页面名]]是可以的。頁面名。（我好像沒有見過[[::页面名]]這樣的語法。）--SolidBlock^留言 2017年8月5日 (六) 05:12 (UTC)

雖然不標準，但這之前好像是可以的。--A2093064#Talk 2017年8月5日 (六) 06:23 (UTC)

可以使用[[:{{FULLPAGENAME::页面名}}]]：頁面名。這樣就可以保證創建鏈接了。--SolidBlock^留言 2017年8月7日 (一) 08:39 (UTC)

我猜你是不是搞錯了？[[::頁面名]]以前能被解析器修正為[[:頁面名]]，現在可能規範過不行了，[[::頁面名]]的寫法主要有一些模板會冒號之間插入旗標或者命名空間名，不插入的話就是直接可以指向主空間，以前的取巧寫法，現在嗝屁了。——路過圍觀的Sakamotosan 2017年8月10日 (四) 01:00 (UTC)

是，應該是做了某些修正，使得兩個冒號不再被當成一個冒號連結。--A2093064#Talk 2017年8月10日 (四) 01:05 (UTC)

在繁體模式下被調用了簡體字型

請問系統是否又更新了？請儘快修正，謝謝 --Moonian‧^{♨一盅兩件立即嘆}‧_貢獻 ^主要 _全部 2017年8月11日 (五) 01:16 (UTC)

能舉個例子嗎？--百無一用是書生 (☎) 2017年8月11日 (五) 01:31 (UTC)

再稍為研究一下，發現可能是瀏覽器的問題，因為Google搜尋也有問題（Firefox 56b1，Chrome似乎沒事）。抱歉打攪了！ --Moonian‧^{♨一盅兩件立即嘆}‧_貢獻 ^主要 _全部 2017年8月11日 (五) 01:48 (UTC)

簡繁轉換錯誤？

妳是主人我是僕，具體看IP用戶的編輯注釋留言 --我是火星の石榴（留言） 2017年8月7日 (一) 09:17 (UTC)

CJK Unified Ideographs Extension C裡有「鍊」的類推簡化字「𫔀」（⿰钅柬，U+2B500），Unicode還沒收錄把「拣」的偏旁換成「钅」的那個字（說起來真麻煩😒）。-- By Jimmy Young. (Talk) 2017年8月11日 (五) 05:36 (UTC)

文檔內容調用模塊時參數失效但直接調用則正常

參見testwiki:Template:Rub，在testwiki:Module:Ruby中，我將mw.getCurrentFrame():getParent().args的內容轉換到args（表），然後在testwiki:Template:Rub/doc調用Rub模板，發現一切正常，mw.getCurrentFrame():getParent().args的域規規矩矩到了args中，但是如果是在Template:Rub頁面用{{doc}}的形式查看，發現模板出現了異常，args完全變成了一個空表。但是直接使用{{Template:Rub/doc}}發現結果是正常的。不知道是不是模塊:Arguments有什麼問題。如果我將原模塊中的mw.getCurrentFrame():getParent().args用模塊:Arguments的相應方法代替，反而無論是間接查看文檔還是直接查看文檔頁面都會出錯。所以希望Lua高手幫忙修復一下。--SolidBlock^留言 2017年8月11日 (五) 09:58 (UTC)

建議給小工具中的RefToolbar 2.0的cite web增加dead-url參數

小工具裏面有一個快捷插入參考文獻模板的工具，即en:WP:RefToolbar 2.0，其中的cite web建議增加dead-url=這個參數，可以填yes來表示原連結已失效或填no來表示原連結未失效，詳見此，最好是能夠做成選項按鈕啦。至於yes跟no的不同之處就在於那句「原始內容存檔於YYYY-MM-DD」跟「原始內容存檔於YYYY-MM-DD」。由於在下電腦水平有限，希望有人能幫忙增加此功能，謝謝。 --dqwyy（談笑風生）^{環状線を走り抜けて}_{回覆請ping/mute我} 2017年8月12日 (六) 13:55 (UTC)

(＋)滋磁

，咱一直手動加「|deadurl=no」的說。。。。--⌬胡蘿蔔 _{熱烈慶祝化學成為動員令主題} 2017年8月12日 (六) 13:57 (UTC)

Chrome終於支援zh-hk

可能是舊聞，但也分享一下。Google Chrome自推出以來多年，語言設定長期只設「中文（繁體）」（zh-tw）及「中文（簡體）」（zh-cn）兩項，不設zh-hk，導致在未登入情況下瀏覽中文維基百科時，不可能自動顯示「香港繁體」，至少到2017年初還是如此。然而，在過去數個月的某次更新中，Chrome的語言設定終於加入了「中文（香港）」（zh-hk）的選項。故香港的Chrome使用者只要預先設定使用「中文（香港）」，在未登入情況下瀏覽中文維基百科時便可自動顯示「香港繁體」。--Kevinhksouth (Talk) 2017年8月13日 (日) 13:20 (UTC)

模板表格的繪製

請問如何繪製出如下表格：

查·論·編	XX化合物				[隱藏]
元素周期表區域
屬性α的化合物	化合物A、化合物B
屬性β的化合物	化合物C、化合物D、化合物E

（效果如上圖所示，但沒有表格的邊框線）

即將（1）類型1（周期表式）（2）類型2（分類模板式）這兩種類型的模板整合在一起。（點擊藍鏈查看模板）--Leiem（留言） 2017年8月13日 (日) 05:48 (UTC)

直接拼好像就行了。 --碸中嘌呤的白磷_{萃取 打譜} 2017年8月14日 (一) 01:06 (UTC)

thanks --Leiem（留言） 2017年8月14日 (一) 02:10 (UTC)

音頻播放的問題

例如Help:IPA條目中有很多音頻文件，播放聲音的時候會打開新頁面。有沒有什麼辦法點擊播放後在原頁面播放的？--Leiem（留言） 2017年8月14日 (一) 07:40 (UTC)

Win 10.1 系統，Chrome瀏覽器。--Leiem（留言） 2017年8月14日 (一) 07:46 (UTC)

Tech News: 2017-33

最新技術新聞來自維基媒體技術社群。請將這些變化轉告其他用戶。不是所有的變化都將影響您。翻譯亦已提供。

最近更新

• 行政員現在可以將用戶標記為已確認。以前只有監管員能在大部分wiki上實現這一點。之前允許管理員將用戶標記為已確認的wiki不受影響。 [12]

問題

• 語言列表中顯示對應語言版本條目是優良或特色條目的圖標無法工作。邊欄中鏈至共享資源分類的鏈接同樣無法工作。開發人員正在修復這一問題。 [13][14]

本周更新

• MediaWiki的新版本將於8月15日部署於測試維基及MediaWiki.org。它將於8月16日部署至非維基百科wiki及部分維基百科，並於8月17日部署至所有wiki，參見日曆。

技術新聞由技術新聞編者準備，並由機器人送達 • 貢獻 • 翻譯 • 獲取幫助 • 提供反饋 • 訂閱或退訂。

2017年8月14日 (一) 23:28 (UTC)

維基百科:關注度/提報中的Template:Find sources

由8月12日起，維基百科:關注度/提報中的Template:Find sources 全都不能顯示。是出了甚麼問題？--Nivekin※請留言 2017年8月15日 (二) 02:42 (UTC)

展開上限。——路過圍觀的Sakamotosan 2017年8月15日 (二) 02:50 (UTC)

所以是那位提報了700多條目的朋友引起的問題？--Nivekin※請留言 2017年8月15日 (二) 03:05 (UTC)

估計是，這應該是findsource所能容納的極限（使用Lua代替解析器函數後，現在模板輸出結果就是最小的展開長度），突然有種SM當年的日子？（笑）——路過圍觀的Sakamotosan 2017年8月15日 (二) 03:14 (UTC)

有關Location Map的圖片描述

在國家的層面來說並沒有甚麼太大的問題。但是到了小一些的層面，如州、省、市、縣等，使用Location map就會出現英文圖片描述該州省市縣。例子，點開位置的部分，圖片的描述（游標停在圖片上面的框框）。是否可以修復？--owennson（聊天室、獎座櫃） 2017年8月14日 (一) 17:12 (UTC)

svg圖片，自己改一下上傳一個中文的不就好了，或者改成多語言支持的svg版也行--百無一用是書生 (☎) 2017年8月15日 (二) 01:25 (UTC)

我不擅長改圖再上傳，但如何改成多語言支持的svg版？--owennson（聊天室、獎座櫃） 2017年8月15日 (二) 06:14 (UTC)

Infobox election出錯？

我翻譯了2017年百慕達大選,但不知何解在只加入一張選舉地圖時會顯示四張一樣的選舉地圖，請問是否Infobox election出錯？Tom...........（留言） 2017年8月15日 (二) 07:26 (UTC)

@Tombus20032000： 已修復--A2093064#Talk 2017年8月15日 (二) 09:57 (UTC)

最近更改即將到來的最新變化

我們目前依靠最近更改頭部進行廣而告之的做法可能要改一改了--百無一用是書生 (☎) 2017年8月4日 (五) 02:10 (UTC)

meta被折疊的部分是放在m:MediaWiki:Recentchangestext，而我們是放在MediaWiki:Recentchanges-summary，對應m:MediaWiki:Recentchanges-summary都是不會被折疊的。--A2093064#Talk 2017年8月4日 (五) 02:16 (UTC)

啊，忘了中文版這一點上和別人不一樣了。但是按照目前的新樣式來看，MediaWiki:Recentchanges-summary風格太不協調了，而且太占地方，說白了就是有些難看--百無一用是書生 (☎) 2017年8月4日 (五) 02:31 (UTC)

建議將MediaWiki:Recentchanges-summary的內容放回MediaWiki:Recentchangestext--百無一用是書生 (☎) 2017年8月4日 (五) 04:12 (UTC)

MediaWiki:Recentchanges-summary is collapsed only for users who use the Beta feature 用於編輯覆核的新過濾器. The goal is to have a clearer interface. People using the Beta just need to click to open the collapsed panel and it will remain open.

At the moment, you are missing all information contained on MediaWiki:Recentchanges-summary while using the Beta feature, because MediaWiki:Recentchanges-summary is not used by the Beta feature. You are the only wiki doing it. The best thing to do would be to move the content of MediaWiki:Recentchanges-summary to MediaWiki:Recentchangestext

If you have questions about this particular point, please contact me. :) Trizek (WMF)（留言） 2017年8月4日 (五) 10:46 (UTC)

完成--百無一用是書生 (☎) 2017年8月9日 (三) 04:15 (UTC)

@Shizhao：，根據功能來看，不如將公告欄，質量提升部分放入MediaWiki:Recentchanges-summary，其他工具按照說明放入MediaWiki:Recentchangestext，如何？——路過圍觀的Sakamotosan 2017年8月10日 (四) 06:30 (UTC)

新版最近更改的原意是要默認摺疊最近更改的頭部內容，除了MediaWiki:Recentchanges-summary。這樣才是新版的完整體驗。如果非要露出一些內容來，建議用小工具解決--百無一用是書生 (☎) 2017年8月10日 (四) 09:02 (UTC)

除非想到新地方放這個，不然還是保留的好，太常用了。--Temp3600（留言） 2017年8月11日 (五) 17:01 (UTC)

@Shizhao：最近最近更改頭部出現一行以前沒有的字「在本頁面追蹤本wiki的最近更改。」也跟本節討論內容有關吧？看了下好像是MediaWiki:Recentchanges-summary從外部帶來的，有必要修一下嗎--Kegns（留言） 2017年8月14日 (一) 16:12 (UTC)

改成啥？--百無一用是書生 (☎) 2017年8月15日 (二) 01:19 (UTC)

去掉……--Kegns（留言） 2017年8月15日 (二) 23:26 (UTC)

關於使用Microsoft Edge編輯中文維基百科

如題，本人自月初改用Microsoft Edge瀏覽器，但每次編輯中文維基百科都和自己編輯衝突，有時顯示編輯衝突，再按下儲存仍然顯示編輯衝突；如是者十幾次後方能儲存頁。請問其他維基人有遇上同樣或類似情況嗎？謝謝！ 另外，當我使用Firefox瀏覽器編輯時，直至現時為止沒和自己撞過編輯衝突。--​小楓莊園（後花園） 2017年8月15日 (二) 16:00 (UTC)

連點兩次會跟自己編輯衝突，但是...這是瀏覽器的問題嗎？--A2093064#Talk 2017年8月18日 (五) 04:41 (UTC)

最新頁面的黃色背景消失了

於Phabricator內跟蹤
任務T173556

如題，Special:最新頁面裡面把未巡查的標記為黃色背景，但剛剛看好像消失了。--A2093064#Talk 2017年8月18日 (五) 04:39 (UTC)

好像所有的wiki都出問題了--百無一用是書生 (☎) 2017年8月18日 (五) 06:35 (UTC)

Tech News: 2017-34

最新技術新聞來自維基媒體技術社群。請將這些變化轉告其他用戶。不是所有的變化都將影響您。翻譯亦已提供。

最近更新

• 您現在可以在測試維基和mediawiki.org測試新增的Timeless皮膚。您可以在您的參數設置中啟用它。您也可以在Phabricator報告錯誤。這將很快來到更多wiki。 [15][16]
• 您的監視列表現在已有取消監視頁面的選項。您需要在您的參數設置中打開它。 [17]
• 如果表格有多個列，您經常可以選擇您要排序表格的列。這對於使用Firefox或Safari瀏覽器的用戶而言，可能在某些表格列中無法工作。這一問題現已修復。 [18]
• 相關條目擴展已顯示維基導遊上的相關頁面。您現在會在條目底部看到相關頁面與圖片。之前鏈接顯示在邊欄上。希望使用該擴展的wiki可在Phabricator提出請求。

本周晚些時候的更新

• 視頻現將在所有瀏覽器中以WebM格式播放。之前一些瀏覽器使用Ogg Theora（.ogv）格式。如果您使用Safari、IE或Edge瀏覽器，您在播放高清視頻時播放速度會比較慢。此後我們將使視頻質量更高，文件大小更小。您仍可以上傳Ogg視頻文件。這些會自動轉換為WebM。這並不影響Ogg音頻文件。 [19]
• 編輯窗口中的默認字體將在本周為某些用戶更改。它將不再是瀏覽器默認字體，而是等寬字體。用戶可在其參數設置中更改它。此更改只應用於一些Mac和iOS設備用戶。 [20]
• MediaWiki的新版本將於8月22日部署於測試維基及MediaWiki.org。它將於8月23日部署至非維基百科wiki及部分維基百科，並於8月24日部署至所有wiki，參見日曆。

會議

• 您可以參與IRC上的技術建議會議。在會議中，志願開發者可以徵求建議。會議將於8月23日 15:00（UTC）開始。參見如何加入。
• 您可以參與下周編輯團隊的會議。在會議中您可以告知開發人員哪些問題是最重要的。會議將於8月22日 19:00（UTC）開始。參見如何加入。

技術新聞由技術新聞編者準備，並由機器人送達 • 貢獻 • 翻譯 • 獲取幫助 • 提供反饋 • 訂閱或退訂。

2017年8月21日 (一) 18:00 (UTC)

Timeless皮膚值得期待。--1=0，歡迎加入WP:維基百科維護專題 2017年8月22日 (二) 00:23 (UTC)

Timeless覺得用在維基百科會好難看，可能meta，commons，維基旅遊比較合適--百無一用是書生 (☎) 2017年8月22日 (二) 01:29 (UTC)

MediaWiki的Lua問題

為什麼MediaWiki網站（包括維基百科、miraheze）的模塊控制台（交互式）與真正的Lua不同。在Lua中，直接一行變量名稱即可輸出此變量的值，而MediaWiki則會輸出錯誤。此外，打印table或function的值時，為什麼在MediaWiki不會顯示其編號？如下圖所示：

> "something"
something --Lua
错误 --MediaWiki
> ={}
table: 00988600 --Lua
table --MediaWiki
> =print
function: 64359190 --Lua
function --MediaWiki

個人覺得是MediaWiki使用的Lua版本太舊。--SolidBlock^留言 2017年8月24日 (四) 01:55 (UTC)

正式Lua像table、function的數字更像是內存地址，為了避免暴露，特製版應該隱藏了。至於String那個，不知想說明什麼？——路過圍觀的Sakamotosan 2017年8月24日 (四) 02:11 (UTC)

正式的交互式Lua可以直接在一行輸入一個值以表示print。例如，直接輸入一行"sth"效果等價於="sth"或print"sth"。--SolidBlock^留言 2017年8月24日 (四) 02:15 (UTC)

特製版有不同吧，WP:LUA有提及，就算table，function的輸出同樣需要調用等號。——路過圍觀的Sakamotosan 2017年8月24日 (四) 02:44 (UTC)

新功能？（快速預覽）

剛才在日文版（IP用戶狀態），部分頁面裡，鼠標指向一個藍鏈詞條，會跳出一個快速預覽，還有一個頁面功能設置按鈕，但部分頁面又沒有，這到底是怎麼回事？

Get quick previews of a topic while reading a page

剛才我登陸狀態看了一下自己的用戶設置，好像也沒有對應的項目？

我關心一點，近期有沒有可能全wiki部署，並且默認啟用狀態？--我是火星の石榴（留言） 2017年8月21日 (一) 15:39 (UTC)

你說的是mw:Beta Features/Hovercards吧？--1=0，歡迎加入WP:維基百科維護專題 2017年8月21日 (一) 15:47 (UTC)

是，目前啥情況？簡單看了一下，在進行A/B輪測試？ja已經算完成了？（但為什麼只有部分頁面才有）--我是火星の石榴（留言） 2017年8月23日 (三) 05:38 (UTC)

在中文維基應該可以通過參數設置的測試打開。打開以後應該就能用了吧。--1=0，歡迎加入WP:維基百科維護專題 2017年8月23日 (三) 07:19 (UTC)

這是哪一項啊？看着好像沒有？--我是火星の石榴（留言） 2017年8月24日 (四) 06:00 (UTC)

Beta feature: advanced filters and more options for Watchlists, starting September 5

Hello!

Sorry to write in English. 請幫助翻譯至您的語言!

As you may already know, the Global Collaboration team has created a Beta feature. This feature is on your wiki since few months: "用於編輯覆核的新過濾器". You can activate it in your Beta preferences.

What is this feature again?

This feature improves Special:RecentChanges and Special:RecentChangesLinked. It adds new features that ease vandalism tracking and support of newcomers:

• Filtering - filter recent changes with easy-to-use and powerful filters combinations, including filtering by namespace or tagged edits.
• Highlighting - add a colored background to the different changes you are monitoring. It helps quick identification of changes that matter to you.
• Bookmarking to keep your favorite configurations of filters ready to be used.
• Quality and Intent Filters - those filters use ORES predictions. They identify real vandalism or good faith intent contributions that need help.

You can know more about this project by visiting the quick tour help page.

What's new?

On September 5, the Beta feature will have a new option. Watchlists will have all features available now on the Beta Recent Changes improvements.

If you have already activated the Beta feature "用於編輯覆核的新過濾器", you have no action to take. If you haven't activated the Beta feature "用於編輯覆核的新過濾器" and you want to try the filters on Watchlists, please go to your Beta preferences on September 6. It will not be possible to try the filters only on Recent Changes or only on Watchlist.

Please also note that later in September, some changes will happen on Recent Changes. We will release some features at the moment available in Beta as default features. This will impact all users, but we will provide an option to opt-out. I'll recontact you with a more precise schedule and all the details very soon.

You can ping me if you have questions.

All the best, Trizek (WMF)（留言） 2017年8月24日 (四) 15:59 (UTC)

提議更改內容展開/合併功能的「合併」一詞為「收起」

只是點小意見，對於「合併」一詞在此處出現感到不自然而已。—以上有簽名的留言由R96340（對話）加入於 2017年8月24日 (四) 07:07 (UTC)

可是我看到的是顯示/隱藏。-游蛇脫殼/克勞棣 2017年8月24日 (四) 07:53 (UTC)

...

...

...

兩個預設不一樣（請見原始碼）。--A2093064#Talk 2017年8月24日 (四) 08:41 (UTC)

呃！我現在看到的是展開/摺疊，並無合併。另外，代碼那麼複雜幹嘛？用{{hideH}}與{{hideF}}就好啦！-游蛇脫殼/克勞棣 2017年8月24日 (四) 16:43 (UTC)

PRC Admin 導航模板的小 bug

2017年8月10日，有編者在 Wikidata 浙江省條目中的「所在行政區」屬性新增了「清朝，終於1912年2月12日」這一值，導致浙江全省各區導航模板 above 區域出現了諸如「清朝浙江省寧波市」這樣奇怪的內容，已暫時刪除相關屬性，但考慮到增加帶有「終於……」的值並沒有什麼問題，PRC Admin 導航模板是不是應該修復這一bug。—思域無疆_{大道 事體 機器} 2017年8月22日 (二) 22:41 (UTC)

• 另外國函[2015]75號相關的常州市行政區劃沒有跟進。—思域無疆_{大道 事體 機器} 2017年8月22日 (二) 23:11 (UTC)
• 而且從2015年至今中國區級行政區劃大量調整，現有模板和數據維護門檻過高，我自己調整過寧波市4個區的區劃相關模板，耗費大量時間移動相關的村一級模板和區劃代碼，可以想見由於區劃調整造成的爛尾樓絕對不止常州市一個，應當有更高效的維護方法。—思域無疆_{大道 事體 機器} 2017年8月22日 (二) 23:15 (UTC)
  • 如果你能提供一個具有相同條件的修改方式可以至機器人作業請求請機器人協助。--Zest 2017年8月23日 (三) 16:40 (UTC)
• @Siyuwj： 正確的修復錯誤的方法不是移除數據而是修改Rank，例如這樣。這不是導航模板的錯誤。--GZWDer（留言） 2017年8月24日 (四) 19:40 (UTC)
  •  Siyuwj說讚。—思域無疆_{大道 事體 機器} 2017年8月25日 (五) 00:24 (UTC)

給「顯示預覽」按鈕增加地區字詞轉換菜單的小工具無效

啟用該小工具後，雖然在「顯示預覽」按鈕邊顯示出了轉換菜單，但是無論在菜單中選擇哪一項，效果都與未開啟小工具前無異，顯示的都是我在Special:參數設置中指定的語言變種。——Arnie97（留言） 2017年8月25日 (五) 13:00 (UTC)

User:Liangent我所使用的是正常的。按道理來說，可以啟動或不啟動實時預覽。我是使用了實時預覽的。--SolidBlock^留言 2017年8月25日 (五) 13:48 (UTC)

為什麼在IE和手機QQ瀏覽器下無法正常使用TW

RT，兩個方案（參數設置裡的原版和天邪鬼版本）都不行，連腳本都加載不出，但是Firefox就能正常使用。--Dabao qian（留言） 2017年8月26日 (六) 01:36 (UTC)

• (～)補充：我錯了，IE是本身就不支持，但是手機QQ瀏覽器本來是能用的啊，怎麼說不行就不行了。除此之外，編輯首段，還有緊湊語言鏈接和內容翻譯工具等測試功能也在手機QQ瀏覽器上顯示不出來了。--Dabao qian（留言） 2017年8月26日 (六) 01:53 (UTC)
  • TW不能在IE瀏覽器中使用是開發者自行設定的限制。我在自己的版本中把限制解除了，但是，如果問題只在IE中出現，或者因為使用IE瀏覽器而導致錯誤編輯，您需要自行承擔責任。--逆襲的天邪鬼（留言） 2017年8月26日 (六) 03:18 (UTC)
    • IE是只有TW不能用，其他腳本和測試功能都正常；手機QQ瀏覽器好多腳本和大部分測試功能都掛了。--Dabao qian（留言） 2017年8月26日 (六) 03:21 (UTC)
      • 我診斷不了手機瀏覽器的問題，只能讓別人想辦法了。不過呢，您可以再試試「天邪鬼版本」的TW……--逆襲的天邪鬼（留言） 2017年8月26日 (六) 03:29 (UTC)
        • 本來壞的還沒那麼多來着，剛剛手賤清除了瀏覽器緩存，甚至重裝瀏覽器，結果除了W+其他小工具全掛了。（試了下，不止中文維基，包括粵語、吳語、日語在內的好多語言版本的wiki都是一個毛病，除了W+之外其他所有基於javascript的小工具在手機QQ瀏覽器全部加載不出來，就連ilh和NavFrame這種默認全局啟用的也不行，目前正常的網站只有英文維基、C區和D區）--Dabao qian（留言） 2017年8月26日 (六) 04:30 (UTC)

顯示Wikidata描述的小工具新鮮出爐

一直以來，維基百科手機app以及移動版都會在條目頂端附近顯示維基數據的描述，而桌面版缺少這一功能。我今天下午製作了一個小工具彌補這一缺陷，大家可以試用一下。

importScript('User:Alexander Misel/WikidataDesc.js');

--1=0，歡迎加入WP:維基百科維護專題 2017年8月8日 (二) 02:06 (UTC)

https://img.vim-cn.com/fb/0a7f9427a7f65b6cccfc6684e888ca0ea5708d.png 看來可以用 😂 ホロ|Talk 2017年8月10日 (四) 09:25 (UTC)

app的菜單裡有個編輯描述，要不要也加個編輯功能。 --碸中嘌呤的白磷_{萃取 打譜} 2017年8月10日 (四) 14:52 (UTC)

User:WhitePhosphorus我確實希望有這個功能，但不太會製作界面。我當時打算的是用這個api。界面我想象的是像HotCat那樣的。--1=0，歡迎加入WP:維基百科維護專題 2017年8月11日 (五) 00:34 (UTC)

震驚！該工具目前已支持在頁面直接編輯維基數據的描述！！！感謝User:逆襲的天邪鬼的貢獻。--1=0，歡迎加入WP:維基百科維護專題 2017年8月13日 (日) 11:14 (UTC)

提議此工具加入中文維基小工具列表

User:ArthurLau1997、User:Ken Ookami Horo、User:Manchiu、User:Wang Qiliang和User:Alvinz 提議加入到Special:Preferences中的系統小工具頁面。--1=0，歡迎加入WP:維基百科維護專題 2017年8月18日 (五) 10:46 (UTC)

User:S099001、User:Njzjz、User:Aotfs2013、User:魚頭炮和User:RabbitMeow歡迎大家反饋意見。--1=0，歡迎加入WP:維基百科維護專題 2017年8月18日 (五) 10:50 (UTC)

User:Wcam、User:Datou 1996、User:逆襲的天邪鬼、User:A2093064和User:Willy1018並參與討論。--1=0，歡迎加入WP:維基百科維護專題 2017年8月18日 (五) 10:54 (UTC)

滿不錯的，不過放系統小工具應該弄個簡單的說明頁，並提醒用戶會編輯到Wikidata。--A2093064#Talk 2017年8月18日 (五) 11:04 (UTC)

• (＋)支持：首先感謝編寫者的貢獻。我已試用一段時間，這確實是一個好用的功能。此功能大大方便了對維基數據描述的編輯，同時也有利於閱讀者。我支持將之加入小工具列表。
  此外，我希望各位同仁考慮和討論的是：是否應該對此設計某些保護措施。這個功能大大方便了對維基數據描述的編輯，這就意味着它既大大方便了維基數據的維護，也大大方便了對它的破壞。故此提出這個問題。我提出一些思路供各位參考，例如：維基百科的頁面保護方針是否可以對該頁面上用此工具進行維基數據描述的編輯行為生效？或者如果維基數據支持保護功能的話，是否可以設計一個程序或由維基人將有風險的維基數據描述保護起來？或者不需要技術性保護措施，依靠維基人進行監督維護就可以反破壞？
  這是我目前想到的問題，希望各位考慮。在下加入維基時間不長，資歷尚淺。歡迎各位資深用戶指導、幫助，不勝感激。--ArthurLau1997（留言） 2017年8月18日 (五) 11:29 (UTC)
• (＋)支持，真的是一個很實用的工具，引入到系統gadget想必是墜吼的。另外樓上所說的反破壞問題的確值得考慮。--RabbitMeow ∞ 談笑風生通道 _{一秒的魔法，萬壽之吾江！} 2017年8月18日 (五) 12:07 (UTC)
• (？)疑問：這個小工具是似乎只能從zh讀取數據，不支持從zh-hans，zh-hant，zh-CN，zh-TW，zh-HK等轉寫？例如南京市，這個小工具加載不出來描述，但是在維基數據裡面如果選zh語言，就能看到label為：中國江蘇省省會^{簡體中文（已轉寫）}。--曾晉哲（留言） 2017年8月18日 (五) 12:31 (UTC)
• (＋)支持，不過如果能調整一下小工具的觸發方式就更好了（現在稍微有點靈敏，隨便一點那個區域就彈出來了）。--Jerre Jiang 　討論│參與清理積壓站務　 2017年8月18日 (五) 14:19 (UTC)
• (＋)支持:同上所述，建議支持轉寫顯示--Wang Qiliang · 一起來巡查 · 留言板 2017年8月19日 (六) 03:54 (UTC)
• (＋)支持--Alvinz ^論 2017年8月19日 (六) 10:46 (UTC)
• (＋)支持為什麼不呢--Liuxinyu970226（留言） 2017年8月20日 (日) 12:41 (UTC)
• (＋)支持:是個好用的小工具。水可煮粥，亦可賽艇 ^{聽取蛙聲一片 人生經驗} 2017年8月20日 (日) 17:53 (UTC)
• (＋)支持，相當實用的小工具。應盡快添加至介面。--千村狐兔（留言） 2017年8月21日 (一) 00:34 (UTC)
• (＋)支持實用的小工具。-- Willy1018（留言） 2017年8月21日 (一) 06:48 (UTC)
• (＋)支持實用的小工具。--Wang Qiliang · 留言 2017年8月26日 (六) 08:55 (UTC)

1=0的回覆

1. 我個人不太支持獲取維基數據上的中文語言變種的轉寫。如果都來編同一個變種（zh），那麼我們能很快得到完善的維基數據描述，不管對於簡體編者關注的方面還是繁體，就像中文維基只有一個一樣。
2. 關於容易編輯了，也容易破壞了這一點。我認為，頁面保護同樣運用在小工具上不是做不到，只是這其實是在插手其他站（Wikidata）的維護工作。我們能做到的也許是不默認開啟此小工具。
3. 小工具過於靈敏這一點我認為近期我們就可以解決。（已處理）
4. 小工具的提示文字建議為「顯示與編輯頁面的維基數據描述的工具。由於技術限制，顯示結果不會進行簡繁轉換，請不要把原有描述在繁簡上進行更改。」

以上--1=0，歡迎加入WP:維基百科維護專題 2017年8月19日 (六) 08:12 (UTC)

為何不直接轉成簡體、繁體和zh同時保存呢？--百無一用是書生 (☎) 2017年8月22日 (二) 09:17 (UTC)

因為有地區詞的問題，所以覺得還是暫時不加此功能為好。--1=0，歡迎加入WP:維基百科維護專題 2017年8月24日 (四) 03:05 (UTC)

記得有個繁簡轉換的API啊，不支持地區詞轉換嗎？--百無一用是書生 (☎) 2017年8月24日 (四) 03:30 (UTC)

小工具已加入列表

小工具目前已加入系統的小工具列表。User:Alexander Misel/WikidataDesc.js這個用戶js頁面將會保留，作為測試小工具和老用戶遷移之用。小工具加入之事已在公告欄進行公告。有問題請及時反饋給我。--1=0，歡迎加入WP:維基百科維護專題 2017年8月24日 (四) 03:05 (UTC)

測試功能「內容翻譯」的時區處理有誤

以本地時區 UTC+8 為例，剛編輯過的頁面會顯示為 8 小時前編輯。——Arnie97（留言） 2017年8月27日 (日) 03:35 (UTC)

importScript返回403？

今日本人修改自己的common.js發現所有引入的文件返回403。

Request URL:https://zh.wikipedia.org/wiki/User:Wang_Qiliang/wikiplus.js?action=raw&ctype=text%2Fjavascript
Request Method:GET
Status Code:403 
Remote Address:91.198.174.192:443
Referrer Policy:origin-when-cross-origin

不清楚這是什麼情況。請求幫助。--Wang Qiliang · 留言 2017年8月26日 (六) 08:57 (UTC)

補充：似乎這種地址就正常了：

Request URL:https://zh.wikipedia.org/w/index.php?title=User:Wang_Qiliang/wikiplus.js&action=raw&ctype=text/javascript
Request Method:GET
Status Code:200 
Remote Address:91.198.174.192:443
Referrer Policy:origin-when-cross-origin

--Wang Qiliang · 留言 2017年8月26日 (六) 09:00 (UTC)

貌似 已修復。--Antigng（留言） 2017年8月27日 (日) 04:37 (UTC)

剛剛看了似乎沒有 已修復。--Wang Qiliang · 留言 2017年8月30日 (三) 04:01 (UTC)

$langcode.wikipedia.org/zh 中的 zh 為何義？

例如「en.wikipedia.org/zh」，直接轉入該語言版本的首頁。我試了除「w」與「wiki」之外的任何英文字母/單詞都是「Page not found」。我以為此處的「zh」代表語言代碼，但似乎並不是，若不信你們可以試試「en」、「ja」、「ko」、「ru」等任何語言代碼。-- By Jimmy Young. (Talk) 2017年8月30日 (三) 12:02 (UTC)

不一定： https://en.wikipedia.org/wiki/Ru --巡查員AndyAndyAndyAlbert（討論頁|簽到） 2017年8月30日 (三) 12:07 (UTC)

@AndyAndyAndyAlbert：請審題。你寫的是「wiki/Ru」，不是「Ru」。-- By Jimmy Young. (Talk) 2017年8月30日 (三) 12:09 (UTC)

就是繁簡轉換的url重寫，你可以理解為zh.wikipedia.org/(zh-cn)/$1 -> zh.wikipedia.org/w/index.php?title=$1&variant=zh-cn。——路過圍觀的Sakamotosan 2017年8月30日 (三) 12:11 (UTC)

唷！我竟然把它忘記了（腦子瓦特了，羞 --  By Jimmy Young. (Talk) 2017年8月30日 (三) 12:15 (UTC)

讓維基變成黑底綠字的小工具現已支持vector皮膚

經過我從英文維基借鑑以及修改，該小工具不再只支持monobook皮膚，現已支持vector皮膚。大家可以在參數設置-小工具中啟用。效果如右圖。 --1=0，歡迎加入WP:維基百科維護專題 2017年8月26日 (六) 08:00 (UTC)

我先前稍微試用了一下，很好看，唯一的缺點是會讓使用者名稱旁的兩個通知圖示消失。--冥王歐西里斯（留言） 2017年8月31日 (四) 02:46 (UTC)

希望引入enwiki的File Upload Wizard

中文維基的Wikipedia:上傳界面難看，且給人一個空模板讓別人填，不必要地增大了上傳文件的難度。假如一個新手，不懂代碼，也不懂什麼是模板，是否就傳不了文件了呢？不得不說，在現在這個時代，文件上傳嚮導（File Upload Wizard）是大勢所趨。在C區人們也常常會使用類似的嚮導來上傳文件。希望有人對此提議感興趣。--1=0，歡迎加入WP:維基百科維護專題 2017年7月27日 (四) 10:23 (UTC)

相關過往討論供參考：提議引入但不了了之、改上傳界面的排版。 --碸中嘌呤的白磷_{萃取 打譜} 2017年7月27日 (四) 10:26 (UTC)

之前討論過，在下也表示支持，不過最後不了了之，不知是否存在技術上的問題。--Jerre Jiang 　討論│參與清理積壓站務　 2017年7月27日 (四) 10:47 (UTC)

需要去P站提請求吧。——꧁༺星耀晨曦༻꧂（留言） 2017年7月27日 (四) 11:59 (UTC)

唉，等等。英文維基百科的File Upload Wizard不是Upload Wizard擴展，是用JS寫的腳本。——꧁༺星耀晨曦༻꧂（留言） 2017年7月27日 (四) 12:30 (UTC)

確實不是。只是需要翻譯的量有點大而已。翻譯過來我覺得就可以用。--1=0，歡迎加入WP:維基百科維護專題 2017年7月27日 (四) 13:01 (UTC)

代碼寫在這裡了，想用新的就去翻譯吧。另MediaWiki:FileUploadWizard.js只有管理員才能創建。--Q_whisper 2017年7月30日 (日) 04:14 (UTC)

要建就先建立在Draft:MediaWiki:FileUploadWizard.js--1=0，歡迎加入WP:維基百科維護專題 2017年7月30日 (日) 04:45 (UTC)

建草稿沒什麼用吧，用不了也沒法測試。--Q_whisper 2017年7月30日 (日) 05:06 (UTC)

用得了，也有法測試。測試完沒問題自然就可以改到正式MediaWiki空間了。--1=0，歡迎加入WP:維基百科維護專題 2017年7月31日 (一) 02:53 (UTC)

@Vozhuo、星耀晨曦：小小地hack了一下，你們就可以在Draft:MediaWiki:FileUploadWizard.js這裡改了。--1=0，歡迎加入WP:維基百科維護專題 2017年7月31日 (一) 03:03 (UTC)

would like to help if possible.--Temp3600（留言） 2017年7月31日 (一) 20:49 (UTC)

今天進行了一次測試。目前大部分文字已經翻譯，建議大家一起檢查一下。--1=0，歡迎加入WP:維基百科維護專題 2017年8月4日 (五) 08:01 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ special:permalink/455145181073到1085行還需要翻譯，涉及到編輯摘要部分，抱歉我不太懂行話怕弄出翻譯腔。另外要不要考慮繁簡？ --碸中嘌呤的白磷_{萃取 打譜} 2017年8月4日 (五) 08:15 (UTC)

另外翻譯的過程中發現Non-free architectural work、Non-free title-card、Non-free speech、Non-free AUSPIC、Non-free Finnish Defence Forces、Non-free with ND這些模板沒有（也許還有）。--1=0，歡迎加入WP:維基百科維護專題 2017年8月4日 (五) 08:20 (UTC)

剛剛建了一個{{Non-free title-card}}，不過有些地方不太會翻譯。另外Non-free speech、Non-free AUSPIC、Non-free Finnish Defence Forces這三個模板在英文維基使用量極少，所以也沒太大必要跟着建，直接刪掉選項就行。--Q_whisper 2017年8月5日 (六) 13:30 (UTC)

@WhitePhosphorus、Vozhuo、星耀晨曦、Datou 1996、Clear Sky C：簡體版目前差不多了，歡迎大家來試用。有問題請隨時更改。--1=0，歡迎加入WP:維基百科維護專題 2017年8月6日 (日) 04:30 (UTC)

會盡力支持閣下對維基基礎建設和大陸維基發展-- 晴空·和岩 o(*≧▽≦)ツ┏━┓·協作計劃·中國大百科全書維基對應條目 2017年8月6日 (日) 04:32 (UTC)

「請注意我們強調的是「完全由自己製作」。……」等紅色框框內的內容，仍然還未正常顯示。--皇帝心態·被人利用·支持輪子·阻擋串聯·強推站外封禁·濫權の管理員（留言） 2017年8月6日 (日) 05:29 (UTC)

@KOKUYO：這屬於警告內容，默認是不顯示的，只給特定的用戶顯示。--Q_whisper 2017年8月6日 (日) 11:41 (UTC)

知道了。我在看英語維基百科頁面有出現，以為這是給所有人看的。--皇帝心態·被人利用·支持輪子·阻擋串聯·強推站外封禁·濫權の管理員（留言） 2017年8月7日 (一) 11:07 (UTC)

額。。怎麼試用。——꧁༺星耀晨曦༻꧂（留言） 2017年8月6日 (日) 05:50 (UTC)

同上，怎麼試用Orz...--Jerre Jiang 　討論│參與清理積壓站務　 2017年8月6日 (日) 08:20 (UTC)

找到了——꧁༺星耀晨曦༻꧂（留言） 2017年8月6日 (日) 08:28 (UTC)

我覺得最好在現在的上傳頁面寫一個通知，「新版上傳工具正在測試，歡迎試用」之類的，要不然測試量太少了。--Q_whisper 2017年8月6日 (日) 11:21 (UTC)

同意-- 晴空·和岩 o(*≧▽≦)ツ┏━┓·協作計劃·中國大百科全書維基對應條目 2017年8月6日 (日) 12:54 (UTC)

{{Non-free architectural work}} {{Non-free Old-50}} {{Non-free Old-70}} {{Non-free with ND}}這四個模板還需創建，請大家協助。腳本里還有幾個因為英文維基使用量極少所以注釋掉的模板，要是有人覺的有用的話也可以創建。--Q_whisper 2017年8月8日 (二) 12:06 (UTC)

{{Non-free architectural work}}創建之前可臨時使用{{promotional}}代替，例如File:New_Corpus_Christi_Harbor_Bridge.jpg--Wcam（留言） 2017年8月8日 (二) 12:25 (UTC)

關於工具中的連結

User:Wcam堅持做出這項編輯，將有著更多實際上傳注意事項的「Wikipedia:合理使用」，改成僅說明使用原則「Wikipedia:非自由內容使用準則」。有鑑於這是幫助用戶上傳的工具，明顯有更多參考指引的「Wikipedia:合理使用」能給予更多幫助，對此請各位提出意見。--皇帝心態·被人利用·支持輪子·阻擋串聯·強推站外封禁·濫權の管理員（留言） 2017年8月8日 (二) 01:39 (UTC)

另外「Wikipedia:非自由內容使用準則」列出的10項原則，在新工具都有提及或要求。

非自由內容使用準則十項原則與新工具早有的要求

1. NFCC1：無自由等效作品。→「請記住，您將需要證明：」該紅框便有提醒。
2. NFCC2：尊重作品的商機。→「請記住，您將需要證明：」該紅框便有提醒。
3. NFCC3：有限使用。→「請記住，您將需要證明：」該紅框便有提醒。
4. NFCC4：事前發表。→上傳工具已經要求要提出檔案來源，這必定代表。
5. NFCC5：內容。→上傳工具已經告知非自由內容檔案時，針對的條目應該有怎樣的內容。
6. NFCC6：針對媒體的方針。→上傳工具已經有要求。
7. NFCC7：至少一篇條目使用。→上傳工具一開始便要求指定1篇條目。
8. NFCC8：條目中的意義。→「請記住，您將需要證明：」該紅框便有提醒。
9. NFCC9：場合的限制。→上傳工具一開始便要求指定1篇條目，並且對於其他類型的頁面亦有防範。
10. NFCC10：圖像描述頁。→上傳工具已經指定要填寫了。

至於「Wikipedia:合理使用」提及的版權法律注意事項，上傳工具根本沒有篇幅提供，自然要使用連結提醒別人注意。一個是只是因為有人說它是方針所要放，一個是提供更多注意細節，例如不應該上傳30秒以上的音訊檔案。哪個有用明顯很清楚。--皇帝心態·被人利用·支持輪子·阻擋串聯·強推站外封禁·濫權の管理員（留言） 2017年8月8日 (二) 02:05 (UTC)

關於非自由圖片的規定當然要以正式方針為準，Wikipedia:合理使用里內容不多，連指引都算不上，並且其主要內容自2007年成型以來已有近10年未大幅更新，已不再適合作為指引新手之用，還有可能誤導使用者。如果能有更準確且完備的指引（例如將Wikipedia:合理使用/草稿翻譯完成並通過為正式指引），則更適合作為上傳者參考。但在此之前，作為正式方針且必須普遍遵守的Wikipedia:非自由內容使用準則，強調再多遍也不為過。--Wcam（留言） 2017年8月8日 (二) 12:01 (UTC)

內容不多？至少是跟實際上傳有關的指示內容，而且對於新手來說，這比你給的更有用。而既然是指示其他人頁面，你覺得不符合現狀，或者可以改得更好，就自己修改、或找人討論修改，這點管理員應該懂吧？如果你後面的理由要成立，我歸結兩點：

1. 「連指引都算不上」→看起來Wcam是主張，咱們維基百科除了方針指引的內部連結，其他都不應該添加。或許這些非方針指引的頁面應該都刪除，免得誤導使用者。
2. 「自2007年成型以來已有近10年未大幅更新」→看起來Wcam是主張，假設有個規則從2007年都持續運作、沒什麼變化、也沒什麼更新，他自己可以主張規則太舊，照自己的方法來。

我覺得這個維基百科運作機制的解釋獨步其他人。就像原來方針指引的共識，可以自動等同於某個頁面添加什麼連結的共識，怪不得我跟不上。--皇帝心態·被人利用·支持輪子·阻擋串聯·強推站外封禁·濫權の管理員（留言） 2017年8月9日 (三) 10:21 (UTC)

因為Wcam看起來會一直堅持下去，那我改成兩個都放；如果Wcam覺得這合理使用的頁面介紹不夠好，那他自己應該勇於修改、或者提刪該頁面。@Alexander Misel、WhitePhosphorus、Datou 1996、星耀晨曦、Vozhuo：@Temp3600、Clear Sky C：你們幾位覺得如何呢？--皇帝心態·被人利用·支持輪子·阻擋串聯·強推站外封禁·濫權の管理員（留言） 2017年8月9日 (三) 10:39 (UTC)

(：)回應：我的確認為Wikipedia:合理使用的內容不夠好，於是有參與過Wikipedia:合理使用/草稿頁面的翻譯，並希望其最終能成為正式指引。請問KOKUYO閣下在一味指責別人的同時，為此做過什麼工作？如果一個頁面不是正式方針指引的一部分，則其鏈接不適合出現在一個重要的功能性界面上的諸如「我已經閱讀了維基百科XXX規定和標準」這樣的句子之上，因為你提供的鏈接其實根本不是維基百科規定和標準的一部分。涉及到維基百科的規定，一定要以正式方針指引為準，因此我仍然不能完全贊同你兩個都放的做法。如果使用諸如「我們建議上傳者參考Wikipedia:合理使用中提供的建議做法」的表述，我認為才可以接受。--Wcam（留言） 2017年8月9日 (三) 14:17 (UTC)

我覺得Wikipedia:合理使用夠用，或許也有很多人也覺得夠用，覺得非常不夠用的就只有你，結果說成是我的問題？還是2015年沒有參與這個草稿翻譯的維基百科人，都沒有發表意見的權利啊，原來現在維基百科是這樣運作的？或者今天維基百科的所有合理使用，都要經過你點頭才能討論，這個官威真的好大，或許我翻譯這個工具前還得經過你的點頭才行？至於你最後所說的意見，本身就是你誤解維基百科的運作模式，完全沒有意義。在這裡，「兩者並列」與以「方針指引為主軸」完全沒有關係，你的做法只是增加沒有實際用途的文字罷了。--皇帝心態·被人利用·支持輪子·阻擋串聯·強推站外封禁·濫權の管理員（留言） 2017年8月10日 (四) 01:27 (UTC)

兩位都冷靜一下，感覺這不是一個很大的問題呀，實在不行乾脆將兩個指引的內容合併到一起不就行了 囧rz...--Jerre Jiang 　討論│參與清理積壓站務　 2017年8月10日 (四) 01:49 (UTC)

Wikipedia:合理使用本來就得跟其他現有方針指引共通、互相補充，甚至該頁面便提及「具體的『合理使用』判斷準則，請參見Wikipedia:合理使用準則。以下簡單說明中文維基百科各種可能的合理使用形式，如果您有任何疑慮，歡迎到Wikipedia:互助客棧/求助詢問。」。且維基百科本來就不存在只看方針指引的情況，任何方針指引都會有論述、資訊頁、過往討論紀錄等，作為理解的這些規則的參考依據。但Wcam的理解好像跟大家不一樣。--皇帝心態·被人利用·支持輪子·阻擋串聯·強推站外封禁·濫權の管理員（留言）

不過@Datou 1996：您的意見確實不錯，英語維基百科也是直接在Wikipedia:合理使用中插入Wikipedia:非自由內容使用準則的內容。這樣修改合理使用頁面後，上傳工具這邊就能同時保留非自由內容使用準則的內容、又能維持上傳工具的簡潔了。--皇帝心態·被人利用·支持輪子·阻擋串聯·強推站外封禁·濫權の管理員（留言） 2017年8月10日 (四) 02:45 (UTC)

既然英文版也不嫌長，就包進去吧。互不相沖。翻譯工程浩大，得慢慢來。--Temp3600（留言） 2017年8月11日 (五) 17:06 (UTC)

反饋

於Phabricator內跟蹤
任務T173631

上傳文件顯示到「正在上傳」界面就卡住了，雖然文件上傳成功，但無法跳轉到「上傳成功」界面，我兩次上傳都遇到這種問題，應該不是我網絡的問題。--Q_whisper 2017年8月17日 (四) 04:43 (UTC)

我也遇到同樣問題。Chrome瀏覽器的Console顯示Refused to display 'https://zh.wikipedia.org/w/api.php' in a frame because it set 'X-Frame-Options' to 'DENY'.，可能是中文維基api的設置的問題。--1=0，歡迎加入WP:維基百科維護專題 2017年8月19日 (六) 11:10 (UTC)

@Vozhuo：此bug已修復。上傳文件的結果效果圖--1=0，歡迎加入WP:維基百科維護專題 2017年8月21日 (一) 14:27 (UTC)

我最近在填使用的條目時總是出現「xxx該頁面不屬於條目名字空間。非自由版權文件只能在屬於主名字空間的條目頁面使用……」有人遇到這樣的問題嗎？--Q_whisper 2017年8月29日 (二) 06:46 (UTC)

我現在傳什麼圖片都遇到上面的警告，死活傳不上去，這是什麼情況@Alexander Misel。--Q_whisper 2017年8月29日 (二) 13:51 (UTC)

我之前傳文件都沒有遇到這個問題啊。會不會是你填條目名稱的時候有問題？--1=0，歡迎加入WP:維基百科維護專題 2017年8月29日 (二) 14:50 (UTC)

我測試了一下，確實有這個問題，跟繁簡使用應該無關。--皇帝心態·被人利用·支持輪子·阻擋串聯·強推站外封禁·濫權の瘋狂病氣管理員（留言） 2017年8月29日 (二) 15:16 (UTC)

經檢查，問題出在天邪鬼的Special:Diff/45795149這筆編輯。因為var ns = pg.getAttribute('ns');這個變量返回的ns值其實是一個string類型的"0"，用!=運算符才能得到正確的比較結果。只有兩邊都是數值類型的時候才能用!==去判斷。--1=0，歡迎加入WP:維基百科維護專題 2017年8月29日 (二) 16:03 (UTC)

建議將文件上傳嚮導設為默認上傳工具

經過前一階段的測試和改進，文件上傳嚮導已經具備了其應有的功能，而且簡繁上也得到了支持。感謝User:KOKUYO、User:Vozhuo、User:Wcam等的參與。

現在正式建議該嚮導成為中文維基百科的默認上傳工具，原版可以繼續保留在WP:上傳/old作為有經驗用戶的一個選擇。歡迎大家表達看法。--1=0，歡迎加入WP:維基百科維護專題 2017年8月23日 (三) 09:59 (UTC)

想把UI改成OOjs UI,折騰了半天好麻煩....--百無一用是書生 (☎) 2017年8月23日 (三) 13:15 (UTC)

還有點遺漏，{{Non-free architectural work}} {{Non-free Old-50}} {{Non-free Old-70}} 這三個模板還沒建，腳本里第1505行尚未本地化。--Q_whisper 2017年8月23日 (三) 13:18 (UTC)

由於中文維基沒有ImageTaggingBot，所以1505行不用漢化。幾個模板建起來應該不難吧。--1=0，歡迎加入WP:維基百科維護專題 2017年8月23日 (三) 13:52 (UTC)

支持使用上傳嚮導。--Q_whisper 2017年8月25日 (五) 13:18 (UTC)

不用另外建立Wikipedia:上傳/old的吧，直接Special:Upload就可以返回到舊版上傳表單。--Dabao qian（留言） 2017年8月26日 (六) 03:00 (UTC)

是把原來的頁面移動到Wikipedia:上傳/old。要知道Special:Upload和現在的Wikipedia:上傳也是有區別的。--1=0，歡迎加入WP:維基百科維護專題 2017年8月29日 (二) 03:04 (UTC)

(－)反對，沒有繁簡轉換，單這個理由就足以令這個工具不適合作為默認的選項。另，提案人在沒有公告徵求意見，沒有公告討論結果的情形下自行修改了上傳頁面。--Antigng（留言） 2017年8月31日 (四) 10:55 (UTC)

[21][22]這是你說的沒有簡繁轉換？我不懂你說哪裡。--1=0，歡迎加入WP:維基百科維護專題 2017年8月31日 (四) 12:28 (UTC)

點擊「點此開始上傳嚮導」 -> 點擊左上角切換到另一個語言，頁面又跳回到開始頁面，似乎js不忍url里的variant參數--百無一用是書生 (☎) 2017年8月31日 (四) 12:48 (UTC)

其實認的，只不過左上角的語言變種切換不會認你還加載着js。提前在參數設置里設置好某種語言變種就好，誰會開了嚮導再改語言？--1=0，歡迎加入WP:維基百科維護專題 2017年8月31日 (四) 13:01 (UTC)