用戶討論:A2569875/存檔/2022年/7-9月
本頁是以往討論的存檔。請勿編輯本頁。若您想發起新討論或重啟現有討論,請在當前討論頁進行。 |
過去一個月(2022年4月1日至2022年4月30日)內,中文維基百科之重要人事及政策變動大致如下,個別項目基本依變動或施行時間先後排序:
方針與指引重要變動:重大的方針與指引修訂。過去一個月內,互助客棧方針區共有方針與指引相關新提案23項,另有4項方針與指引相關提案獲得通過:
- 《管理員的離任方針》:在〈長期沒有活動解任〉一節中補充不活動管理員通知模板。(討論紀錄)
- 《一級行政區道路特殊收錄限制列表》:增列英國公路之收錄限制,並更名為《道路特殊收錄限制列表》,指引範圍不再限於一級行政區公路。(討論紀錄)
- 《繁簡處理指引》:允許在適當情況下直接調整頁面用字以修復錯誤之繁簡轉換,而無需再進行手工轉換。(討論紀錄)
- 《過度分類指引》:將〈包含主觀性的標準〉一節確立為指引。(討論紀錄)
其他方針與指引雜項修訂,包括未於互助客棧方針區討論而進行之小修改、方針與指引之相應修訂或事實性修訂等。請核查此等修訂,若有需要,可提案至互助客棧方針區復議。
- 方針:《方針與指引》、《有償編輯方針》、《破壞方針》、《管理員方針》、《可供查證方針》、《行政員方針》、《新頁面巡查方針》、《侵犯著作權方針》、《用戶名方針》、《共識方針》、《刪除方針》、《命名常規》、《編輯禁制方針》、《忽略所有規則》、《文件使用方針》及《非原創研究方針》。
- 指引:《格式手冊》、《簽名指引》、《命名常規(音樂)》、《假定善意指引》、《不要傷害新手指引》、《格式手冊(列表)》、《關注度指引(運動員)》、《重定向指引》、《格式手冊(虛構)》、《申請成為管理人員指引》、《關注度指引(地理特徵)》、《列明來源指引》、《關注度指引(學者)》、《可靠來源佈告板評級指引》、《關注度指引(組織)》、《利益衝突指引》、《可靠來源指引》、《草稿命名空間指引》及《權限申請指引》。
其他重要社群動態:此處列出的動態雖不一定與正式方針或指引有關,惟對維基百科之社群或站務運作有一定影響。
- 社群決定就安全投票問題訂立管理員選舉暫行規定,惟相關規定細節尚待修訂。(討論紀錄)
- Citation/CS1之Citation/CS1/Configuration、Whitelist及Identifiers等子模組獲得更新,新增「name-list-style」與「url-access」參數,相容於既有參數(討論紀錄);後新增「chapter-url-access」與「map-url-access」參數,臨時修復語言代碼顯示問題、改善模板顯示方式,並進行大規模拆分整理,啟用COinS、Error、People、Links及Language等子模組,並調整Configuration、Identifiers、Utilities及Whitelist等子模組,使主模組得以大幅精簡。(討論紀錄)
- 過去一個月內,共有1名維基人獲提名維基獎勵並通過:老喬尼獲授維基翻譯專家。
模板 Vae2
看到你改了模板 {{Va}},模板{{Vae2}}應該也有同樣的問題,主要用在WP:基礎條目,麻煩有空看一下。--Kethyga(留言) 2022年8月18日 (四) 15:17 (UTC)
- (:)回應:@Kethyga:追蹤了其引用的模板和模組,已修改兩處Special:Diff/73268643和Special:Diff/73268660,麻煩有空複查下有無生效。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕](☎️·☘️) 2022年8月18日 (四) 16:10 (UTC)
- 在Wikipedia:基礎條目/第五級/人物/作家及撰稿人,Vae2 提示「Lua錯誤:too many expensive function calls。」,好像之前沒有出現。--Kethyga(留言) 2022年8月19日 (五) 00:47 (UTC)
- @Kethyga:請閱讀舊版Doc頁(我沒修改Doc頁,舊版的{{Va}}也是重複用500次報錯。Vae2舊版使用的功能不同 不會報錯){{Va}}的Doc頁template:Va/doc,裏頭有寫到「本模版有使用魔術字……,此魔術字需要許多資源,因此同一頁面此模版中出現超過500個,可能會無法正常顯示」,如果你希望能解掉重定向問題,就無法避免模板限制。不可能魚與熊掌一起兼得,要解決重定向問題就要承擔模板限制後果、要解決模板限制問題就要放棄重定向問題的解決,如需在現況同時解決重定向和模板限制問題,請嘗試拆分頁面直到每頁少於500次模板引用。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕](☎️·☘️) 2022年8月19日 (五) 00:56 (UTC)
- 那感覺還是能夠顯示好一些,重定向的似乎沒有那麼多,之前提需求沒想到現在的後果。--Kethyga(留言) 2022年8月19日 (五) 01:04 (UTC)
- @Kethyga:已暫時改回不識別重定向的版本,在Wikipedia:基礎條目/第五級/人物/作家及撰稿人的WP:模板限制解決,但重定向問題重新出現。WP:模板限制的另一個解方是拆分Wikipedia:基礎條目/第五級/人物/作家及撰稿人到每頁500條目。哪個比較好(我不希望我程式白寫了)-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕](☎️·☘️) 2022年8月19日 (五) 01:19 (UTC)
- 抱歉,暫時沒想到好辦法。Wikipedia:基礎條目/第五級/人物/作家及撰稿人或許可以像英維一樣考慮由機械人更新 {{icon}},不用模板 {{Vae2}}。這個頁面是翻譯自英維,拆分後不方便比對。--Kethyga(留言) 2022年8月19日 (五) 02:09 (UTC)
- (:)回應@Kethyga:其實拆分也不難啊,先把{{Vae2}}中special:diff/73272611的
ignore_redirect=
改成no即抓取重定向模式,然後預覽Wikipedia:基礎條目/第五級/人物/作家及撰稿人頁面,看哪個章節WP:模板限制爆掉了,就把那個章節拆分成諸如Wikipedia:基礎條目/第五級/人物/作家及撰稿人/1然後再看看拆完後哪個章節WP:模板限制爆掉了,就把那個章節拆分成諸如Wikipedia:基礎條目/第五級/人物/作家及撰稿人/2以此類推,直到所有模板正常顯示,就可以了,反正頁面太長也不方便閱讀,如何?這樣就能解決模板爆掉問題也能解決重定向問題,一舉兩得。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕](☎️·☘️) 2022年8月19日 (五) 03:14 (UTC)- 基礎條目第5級里,除了作家這個,其他的頁面應該也有不少鏈出超過500的,比如Wikipedia:基礎條目/第五級/人物/運動員,鏈出有將近12000,如果大動作改動感覺需要條目討論。--Kethyga(留言) 2022年8月19日 (五) 03:21 (UTC)
- (:)回應@Kethyga:我更換了一下判定方式Special:Diff/73276547似乎可以繞過Wikipedia:模板限制#高開銷解析器函數調用次數限制,但運算時間會長一些。目前看Wikipedia:基礎條目/第五級/人物/運動員和Wikipedia:基礎條目/第五級/人物/作家及撰稿人均能正常顯示(使用重定向標示小工具看到是重定向的頁面均有正常識別),您看看目前這樣行不。因為怕運算時間會長一些會超時,所以想請您複查是否所有頁面都沒問題,如有問題我就再改回舊模式。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕](☎️·☘️) 2022年8月19日 (五) 07:23 (UTC)
- 感謝。和其他條目相比,沒有感覺到明顯的網頁卡頓。--Kethyga(留言) 2022年8月19日 (五) 07:41 (UTC)
- (:)回應@Kethyga:我更換了一下判定方式Special:Diff/73276547似乎可以繞過Wikipedia:模板限制#高開銷解析器函數調用次數限制,但運算時間會長一些。目前看Wikipedia:基礎條目/第五級/人物/運動員和Wikipedia:基礎條目/第五級/人物/作家及撰稿人均能正常顯示(使用重定向標示小工具看到是重定向的頁面均有正常識別),您看看目前這樣行不。因為怕運算時間會長一些會超時,所以想請您複查是否所有頁面都沒問題,如有問題我就再改回舊模式。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕](☎️·☘️) 2022年8月19日 (五) 07:23 (UTC)
- 基礎條目第5級里,除了作家這個,其他的頁面應該也有不少鏈出超過500的,比如Wikipedia:基礎條目/第五級/人物/運動員,鏈出有將近12000,如果大動作改動感覺需要條目討論。--Kethyga(留言) 2022年8月19日 (五) 03:21 (UTC)
- (:)回應@Kethyga:其實拆分也不難啊,先把{{Vae2}}中special:diff/73272611的
- 抱歉,暫時沒想到好辦法。Wikipedia:基礎條目/第五級/人物/作家及撰稿人或許可以像英維一樣考慮由機械人更新 {{icon}},不用模板 {{Vae2}}。這個頁面是翻譯自英維,拆分後不方便比對。--Kethyga(留言) 2022年8月19日 (五) 02:09 (UTC)
- @Kethyga:已暫時改回不識別重定向的版本,在Wikipedia:基礎條目/第五級/人物/作家及撰稿人的WP:模板限制解決,但重定向問題重新出現。WP:模板限制的另一個解方是拆分Wikipedia:基礎條目/第五級/人物/作家及撰稿人到每頁500條目。哪個比較好(我不希望我程式白寫了)-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕](☎️·☘️) 2022年8月19日 (五) 01:19 (UTC)
- 那感覺還是能夠顯示好一些,重定向的似乎沒有那麼多,之前提需求沒想到現在的後果。--Kethyga(留言) 2022年8月19日 (五) 01:04 (UTC)
- @Kethyga:請閱讀舊版Doc頁(我沒修改Doc頁,舊版的{{Va}}也是重複用500次報錯。Vae2舊版使用的功能不同 不會報錯){{Va}}的Doc頁template:Va/doc,裏頭有寫到「本模版有使用魔術字……,此魔術字需要許多資源,因此同一頁面此模版中出現超過500個,可能會無法正常顯示」,如果你希望能解掉重定向問題,就無法避免模板限制。不可能魚與熊掌一起兼得,要解決重定向問題就要承擔模板限制後果、要解決模板限制問題就要放棄重定向問題的解決,如需在現況同時解決重定向和模板限制問題,請嘗試拆分頁面直到每頁少於500次模板引用。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕](☎️·☘️) 2022年8月19日 (五) 00:56 (UTC)
- 在Wikipedia:基礎條目/第五級/人物/作家及撰稿人,Vae2 提示「Lua錯誤:too many expensive function calls。」,好像之前沒有出現。--Kethyga(留言) 2022年8月19日 (五) 00:47 (UTC)
您提交的草稿2i已被接受
它被評級為乙級,可在條目的討論頁上查看。對於新條目而言,這是一個很棒的評級,代表本條目的質量在被接受的條目草稿中排在前2%,恭喜您!您可以看看Wikipedia:條目質量評級標準以便了解如何進一步改進該條目。
您可以繼續不斷改善它,維基百科的條目沒有最終版本。非常歡迎您繼續為維基百科做出高質量的貢獻。
感謝您幫助改進維基百科!
🎋🍣 2022年8月20日 (六) 04:23 (UTC)Re: DYK疑似點票故障
您好,這是因為 閣下於投票結束後才修改題目,這會導致點票結果被撤銷,這樣的設計是因為如果有人在投票結束後對題目進行破壞,被破壞的題目不會自動登上首頁。現已人手重新批准。謝謝關注!--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年8月29日 (一) 07:23 (UTC)
- 類別最後的字母是為了疏道而人手添加的,並非錯誤,這通常是多個同類條目同時結束且其他類型已結束的條目數量不多的時候就會有此操作,以免出現更新癱瘓。--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年8月31日 (三) 10:51 (UTC)
負數的移動
抱歉未留意到導航模板處的變化,添麻煩了。--Lt2818(留言) 2022年9月2日 (五) 09:19 (UTC)
- @Lt2818:建議移動回去,因為模板背後是程式語言(維基百科是用php寫成的,不是用「自然語言」構造的),見連字暨減號的說明:「絕大部分程式語言只能使用ASCII,故只能以連字暨減號,而非Unicode字元U+2212 − MINUS SIGN表達數字相減和負數。」是技術限制,輸入U+2212 − MINUS SIGN只會Error(例如U+2212 − MINUS SIGN:
<math>−3</math>
→「解析失败 (SVG(MathML可通过浏览器插件启用):从服务器“http://localhost:6011/zh.wikipedia.org/v1/”返回无效的响应(“Math extension cannot connect to Restbase.”):): {\displaystyle −3} 」、連字暨減號:<math>-3</math>
→「」),負數的輸出也定是連字暨減號,所以所有由模板輸出的數字都無法顯示成「U+2212 − MINUS SIGN」只能是連字暨減號,嘗試修了一個下午修不好(應該說現有框架下根本沒有可下手處),而且連字暨減號也並非「不是減號」,它們是「暨減號」。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕](☎️·☘️) 2022年9月2日 (五) 09:24 (UTC)
- 對Special:PermaLink/73481035確實抱歉,未曾留意。
- 我在User:Lt2818/沙盒測試了一下,似乎Module輸入輸出U+2212都是可行的?只是模板、模塊的編寫要麻煩一些。
- 關於先到先得的部分,當前的NC:先到先得措辭我有參與修改,個人的理解是它只適用於地區詞差異的處理。
- 改用U+2212有爭議的話,我想提到客棧討論比較合適,或許能寫進Wikipedia:格式手冊/日期和數字加以規範。這幾日會比較忙,計劃在數日後提出。
--Lt2818(留言) 2022年9月2日 (五) 09:58 (UTC)
- @Lt2818:您誤會了我說的輸出的意思,我是說一個整數的資料型態,若儲存負二,那麼tostring()後(Module會將number輸出後執行tostring)只會是連字暨減號,不會是U+2212 − MINUS SIGN,這就是我說的技術限制;另一方面U+2212 − MINUS SIGN輸入tonumber()也只會出錯,變nil。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕](☎️·☘️) 2022年9月2日 (五) 10:01 (UTC)
- 我知道程式中如此。但編程中使用的符號與一般情形不大一樣,亦不止此例,如除法用/,冪運算用^,不見得百科內容要去就程式寫法吧。--Lt2818(留言) 2022年9月2日 (五) 10:07 (UTC)
- @Lt2818:負整數#部分的負整數就是仰賴模板自動輸出,所以只能以程式語言輸出的模式。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕](☎️·☘️) 2022年9月2日 (五) 10:10 (UTC)
- 我知道程式中如此。但編程中使用的符號與一般情形不大一樣,亦不止此例,如除法用/,冪運算用^,不見得百科內容要去就程式寫法吧。--Lt2818(留言) 2022年9月2日 (五) 10:07 (UTC)
- @Lt2818:「改用U+2212有爭議的話」並不是說有爭議,是你的操作「你把模板弄壞了」,沒壞別修,但是你沒事隨意操作讓他壞掉了??原本就沒事,也沒壞,你幹嘛移動?你這樣移用 反而東西都壞掉了。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕](☎️·☘️) 2022年9月2日 (五) 10:08 (UTC)
- 依然強烈建議移動回去,不然現在變為模板subst展開掉的模式實在不利維護。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕](☎️·☘️) 2022年9月2日 (五) 10:21 (UTC)
- @Lt2818:實務上根本不可能做到數字的tostring負號變成是U+2212,所以我乾脆直接寫一個全文字串轉換函數直接將「-」硬轉成U+2212,Special:Diff/73488787。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕](☎️·☘️) 2022年9月2日 (五) 14:37 (UTC)
- 太好了。我對Module不大熟悉,由我完成的話估計需要更多時間。--Lt2818(留言) 2022年9月2日 (五) 15:16 (UTC)
- 反向轉換應該就能讓模板/模塊接納U+2212了。您認為是否有必要在格式手冊中統一規定負號的碼點?如果感覺必要性不大的話我就不去提了。--Lt2818(留言) 2022年9月18日 (日) 14:40 (UTC)
- @Lt2818:「反向轉換應該就能讓模板/模塊接納U+2212了」不認為。你這樣一搞,程式碼代碼都要變得很難看,還要「牽套」一層轉換,計算時又要再轉換過去算完要轉換回來,整個代碼變得亂七八糟的,可讀性可預期極差,且無故轉來轉去,浪費效能,導致模板更容易遇到WP:模板限制,而且不排除還有其他因技術限制無法透過文字轉換解決的Case,例如
<math>−3</math>
→「解析失败 (语法错误): {\displaystyle −3} 」(<math></math>
在模塊階段會變成mw:Strip marker而無法讀到裏面的內容,因此無法執行文字替換),因此我十分(-)反對這種作法。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕](☎️·☘️) 2022年9月18日 (日) 14:48 (UTC)- 我的想法是這樣,模板/模塊類似於程式,輸入參數一般也一樣用U+002D - HYPHEN-MINUS。上面說的反向轉換隻適用於少數情況,譬如像Template:整數直接讀頁面名稱的時候。--Lt2818(留言) 2022年9月18日 (日) 15:18 (UTC)
- @Lt2818:其實Template:整數是假的,他是用「-」算完之後才強制替換為U+2212 − MINUS SIGN。這明顯會出問題,沒出問題只是「-」和U+2212 − MINUS SIGN都有重定向頁而已。沒道理要為了這個奇怪的堅持,建立一大堆不必要的重定向頁。--! 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕](☎️·☘️) 2022年9月18日 (日) 15:22 (UTC)
- 您這段話里的U+002D感覺不大對,我理解為U+2212。我看您在−3內文中也用的U+2212,把這個符號用在百科內容(而非程式代碼)中應該是沒問題的。--Lt2818(留言) 2022年9月18日 (日) 15:30 (UTC)
- @Lt2818:模板的Infobox中的導航內部輸入的數值有給定「num = -3」,所以它是用「-1、-2、-3、-4.....」計算完後才強制變成「−1、−2、−3、−4.....」。所以他是用「-」算完之後才強制替換為U+2212 − MINUS SIGN。這明顯會出問題,沒出問題只是「-」和U+2212 − MINUS SIGN都有重定向頁而已。沒道理要為了這個奇怪的堅持,建立一大堆不必要的重定向頁。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕](☎️·☘️) 2022年9月18日 (日) 15:33 (UTC)
- 模板內部的過程我大體上知道的。感覺您在上述兩段留言中混淆了U+002D - HYPHEN-MINUS與U+2212 − MINUS SIGN,因而我的留言可能未得到正確理解。--Lt2818(留言) 2022年9月18日 (日) 15:41 (UTC)
- @Lt2818:模板的Infobox中的導航內部輸入的數值有給定「num = -3」,所以它是用「-1、-2、-3、-4.....」計算完後才強制變成「−1、−2、−3、−4.....」。所以他是用「-」算完之後才強制替換為U+2212 − MINUS SIGN。這明顯會出問題,沒出問題只是「-」和U+2212 − MINUS SIGN都有重定向頁而已。沒道理要為了這個奇怪的堅持,建立一大堆不必要的重定向頁。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕](☎️·☘️) 2022年9月18日 (日) 15:33 (UTC)
- 您這段話里的U+002D感覺不大對,我理解為U+2212。我看您在−3內文中也用的U+2212,把這個符號用在百科內容(而非程式代碼)中應該是沒問題的。--Lt2818(留言) 2022年9月18日 (日) 15:30 (UTC)
- @Lt2818:其實Template:整數是假的,他是用「-」算完之後才強制替換為U+2212 − MINUS SIGN。這明顯會出問題,沒出問題只是「-」和U+2212 − MINUS SIGN都有重定向頁而已。沒道理要為了這個奇怪的堅持,建立一大堆不必要的重定向頁。--! 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕](☎️·☘️) 2022年9月18日 (日) 15:22 (UTC)
- 我的想法是這樣,模板/模塊類似於程式,輸入參數一般也一樣用U+002D - HYPHEN-MINUS。上面說的反向轉換隻適用於少數情況,譬如像Template:整數直接讀頁面名稱的時候。--Lt2818(留言) 2022年9月18日 (日) 15:18 (UTC)
- @Lt2818:「反向轉換應該就能讓模板/模塊接納U+2212了」不認為。你這樣一搞,程式碼代碼都要變得很難看,還要「牽套」一層轉換,計算時又要再轉換過去算完要轉換回來,整個代碼變得亂七八糟的,可讀性可預期極差,且無故轉來轉去,浪費效能,導致模板更容易遇到WP:模板限制,而且不排除還有其他因技術限制無法透過文字轉換解決的Case,例如
- @Lt2818:您誤會了我說的輸出的意思,我是說一個整數的資料型態,若儲存負二,那麼tostring()後(Module會將number輸出後執行tostring)只會是連字暨減號,不會是U+2212 − MINUS SIGN,這就是我說的技術限制;另一方面U+2212 − MINUS SIGN輸入tonumber()也只會出錯,變nil。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕](☎️·☘️) 2022年9月2日 (五) 10:01 (UTC)
- @Lt2818:總而言之,您的意思是 內部參數仍是用U+002D - HYPHEN-MINUS,但百科內文顯示是使用/想辦法讓他輸出U+2212 − MINUS SIGN嗎?-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕](☎️·☘️) 2022年9月18日 (日) 15:59 (UTC)
- 是這樣的,正和
<math>-3</math>
輸入輸出的形式一樣。像Template:Weather box則是二者皆可輸入,但只會輸出U+2212。--Lt2818(留言) 2022年9月18日 (日) 16:38 (UTC)- @Lt2818:如果能證明沒有技術上的疑慮的話你就去提議格式手冊修訂案吧。但是需要強調「由於技術限制,輸入模板的參數可能會需要使用U+002D - HYPHEN-MINUS,但僅要確保輸出為U+2212 − MINUS SIGN即可」,另外不建議把模板直接改成輸出U+2212 − MINUS SIGN,因為如果模板結果要被「再計算」或「再輸入到其他模板」那麼就會出錯,建議的作法是像Template:整數那樣提供一個專門用來轉換的模板,等所有計算都計算完畢之後,確定下一步就是百科內文時,才使用轉換模板。如可能,也把我們這段討論連結過去給其他維基人參考。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕](☎️·☘️) 2022年9月18日 (日) 17:00 (UTC)
- 初步想法是引入en:MOS:MINUS,但我不確定二元運算符號兩側是否加空格,需要研究一下。--Lt2818(留言) 2022年9月19日 (一) 01:55 (UTC)
- @Lt2818:如果能證明沒有技術上的疑慮的話你就去提議格式手冊修訂案吧。但是需要強調「由於技術限制,輸入模板的參數可能會需要使用U+002D - HYPHEN-MINUS,但僅要確保輸出為U+2212 − MINUS SIGN即可」,另外不建議把模板直接改成輸出U+2212 − MINUS SIGN,因為如果模板結果要被「再計算」或「再輸入到其他模板」那麼就會出錯,建議的作法是像Template:整數那樣提供一個專門用來轉換的模板,等所有計算都計算完畢之後,確定下一步就是百科內文時,才使用轉換模板。如可能,也把我們這段討論連結過去給其他維基人參考。-- 今晚 我想來點 [雪菲🐉蛋糕🎂] 配 [娜娜奇🐰鮮果茶☕](☎️·☘️) 2022年9月18日 (日) 17:00 (UTC)
- 是這樣的,正和
Re: 走迷宮演算法問題明顯恰當
您好!如果那邊之後無更多意見,我會在過了2022年9月12日07:55(UTC)之後以人手方式批准通過。另外也請 閣下稍安毋躁,對方若沒有再上線即使再三留言催促也沒有作用。敬請留意,謝謝關注!--街燈電箱150號 開箱維修 抄錶 檢驗證明 2022年9月12日 (一) 06:23 (UTC)
Re:請見諒
原諒鄙人因近期現實事物繁忙而僅留言指出問題不當後則無上線。若管理員認為走迷宮算法明顯恰當則鄙人也無異議。其實依中華民國教育部國語詞典、線上劍橋詞典(即Argothm)較多地將算法指為「計算之方式」或「計算機科學相關解析」,然查閱韋氏詞典才知亦有「為廣義為解決問題的步驟」,先前未認知尚有相關概念,亦為本人才疏學淺之過,望見諒。感謝指出。——詠梅閣—WMLO(留言) 2022年9月12日 (一) 13:24 (UTC)
過去一個月(2022年5月1日至2022年5月31日)內,中文維基百科之重要人事及政策變動大致如下,個別項目基本依變動或施行時間先後排序:
方針與指引重要變動:重大的方針與指引修訂。過去一個月內,互助客棧方針區共有方針與指引相關新提案18項,另有4項方針與指引相關提案獲得通過:
- 《格式手冊(虛構)》:依據社群討論結果,正式訂立虛構事物相關條目之格式手冊,優先適用於既有之《格式手冊》(討論紀錄);後因行文問題而取消指引地位,重新進行修訂。(討論紀錄)
- 《申請成為管理人員指引》:經社群討論通過,訂立安全投票暫行規定,適用於未來一場管理員選舉。(討論紀錄)
- 《草稿命名空間指引》:修訂〈準備草稿〉一節,新增使用Draft categories模板處理草稿內分類的方法。(討論紀錄)
- 《COVID-19條目共識》:移除不影響共識效力之冗餘敘述。(討論紀錄)
其他方針與指引雜項修訂,包括未於互助客棧方針區討論而進行之小修改、方針與指引之相應修訂或事實性修訂等。請核查此等修訂,若有需要,可提案至互助客棧方針區復議。
- 方針:《回退功能方針》、《新頁面巡查方針》、《機械人方針》、《大量帳號建立者方針》、《檔案移動員方針》、《模板編輯員方針》、《介面管理員方針》、《行政員方針》、《管理員方針》、《忽略所有規則》、《共識方針》、《中立的觀點方針》、《避免地域中心方針》、《可供查證方針》、《不要人身攻擊方針》、《刪除方針》、《非原創研究方針》、《編輯禁制方針》、《侵犯著作權方針》、《命名常規》、《生者傳記方針》、《破壞方針》、《封禁方針》、《用戶查核方針》、《傀儡方針》、《用戶名方針》及《維基百科不是什麼》。
- 指引:《關注度指引(學者)》、《關注度指引(運動員)》、《格式手冊(日期和數字)》、《列明來源指引》、《消歧義指引》、《外部連結指引》、《關閉存廢討論指引》、《關注度指引(交通)》、《可靠來源佈告板評級指引》、《關注度指引(人物)》、《不要傷害新手指引》、《格式手冊(列表)》、《頁面分類指引》、《申請成為管理人員指引》、《拉票指引》、《格式手冊(版面佈局)》、《可靠來源指引(醫學)》、《翻譯指引》、《地區詞處理指引》、《重定向指引》、《格式手冊》、《過度分類指引》及《繁簡處理指引》。