萌娘百科討論:討論版/技術實現/存檔/2021年08月
討論版【技術實現】檔案館
關於 "頁面編輯" 中 「小編輯」 和 「摘要」 的相關疑問
請問萌娘百科的頁面編輯在提交更改後是否還能補寫摘要以及勾選或取消勾選「小編輯」?如果不行的話,請問是否考慮增加這個功能? 有時候個人編輯頁面過快往往會導致少寫摘要甚至漏寫摘要以及真的是微小的編輯但實際上卻忘記標記「小編輯」的情況(每次事後發現自己有忘勾「小編輯」,總覺得有負罪感QwQ),這樣也可能會給其他的編輯者增加一些本可以避免的工作量或麻煩。 --馬鴿(討論) 2021年7月28日 (三) 13:49 (CST)
- 這個是mw的問題吧……目前來講沒有方法。--EnMGP編輯者樂然 ✉ 編織希冀,寄於歌聲。 2021年7月28日 (三) 14:02 (CST)
- 提交後MW會將編輯保存為一項不可更改的歷史記錄,目前沒有系統內更改摘要、更改記錄性質和內容的功能。萌百基於MediaWiki,後者沒有這個功能意味著萌百對增加此功能無能為力,若有強烈需求建議向維基媒體基金會提報。不必在摘要和小編輯的問題上苛責自己,不過若能盡善盡美那便是最好的。非常感謝您對萌百做出的貢獻!--サンムル(討論) 2021年7月28日 (三) 14:09 (CST)
- 可以在Special:參數設置里默認全部標記為小編輯。Z E S 2021年7月29日 (四) 17:19 (CST)
- 我其實不建議這麼做……
如果我沒記錯的話,小編輯不需要手動標記巡查。萬一改動比較大的編輯被標記為了小編輯,可能會有逃避巡查的嫌疑。--OIer樂然 ✉ 編織希冀,寄於歌聲。 2021年7月29日 (四) 17:27 (CST)- 這樣啊……因為我是滾動的天空Wiki自動巡查者所以就沒在意這一點……-Z E S 2021年7月30日 (五) 12:30 (CST)
- 就算你是中文維基百科的管理員,在萌娘百科瀏覽、編輯也得遵守萌百的基本法。--94 42 233 2001-8 J-JRE(Discussion) 2021年7月30日 (五) 12:58 (CST)
- 貌似不是。But what I said still stands, 小編輯本來就是給修正筆誤這種無足輕重的編輯準備的,濫用小編輯功能同樣是會被警告的。--EnMGP編輯者樂然 ✉ 編織希冀,寄於歌聲。 2021年7月30日 (五) 13:11 (CST)
- 這樣啊……因為我是滾動的天空Wiki自動巡查者所以就沒在意這一點……-Z E S 2021年7月30日 (五) 12:30 (CST)
- 我其實不建議這麼做……
強烈建議貴站向一部分活躍編輯的常用IP或IP段發放WAF豁免權限
此為#關於萌百是否仍在遭到攻擊和是否可以在一定程度上放寬WAF相關限制的討論的後續討論。
在該討論串曾有人建議按用戶組別放寬WAF限制,但因為WAF由IP進行判定,所以在技術上根本不可能實現。那是否可以向一部分活躍編輯的常用IP來有選擇地進行攔截?我現在都被WAF(當然也包括無法跳轉的拼圖驗證)搞吐了。--北湖3(討論) 2021年7月28日 (三) 17:59 (CST)
巡查都沒這個待遇.jpg
貌似現在只有機器人可以獲得IP豁免權來著(——東方眾 一位史蒂夫 (討論·貢獻)✉❶ 請問您要單推一隻小浣熊嗎? 2021年7月28日 (三) 18:01 (CST)- 🤖可以的話是不是理論上別的也可以?--布洛肯亞雷的反銻研究所(研究成果/找他一同研究) 2021年7月28日 (三) 18:02 (CST)
- Possible, but not feasible. ——拒絕互膜的
M. J. H. 【睽】{{#forargs:}} is evil! 2021年7月28日 (三) 18:06 (CST)
- Possible, but not feasible. ——拒絕互膜的
- 🤖可以的話是不是理論上別的也可以?--布洛肯亞雷的反銻研究所(研究成果/找他一同研究) 2021年7月28日 (三) 18:02 (CST)
- 據我所知,目前運維沒有將IP豁免權開放給自然人用戶的打算,即便是機器人也只是個別申請。--工具人樂然 ✉ 編織希冀,寄於歌聲。 2021年7月28日 (三) 18:04 (CST)
- 站在我個人的角度說,我認為開放這件事情本身也不現實,畢竟我們不知道誰是攻擊者。目前只能通過儘量限制請求數量等手段預防WAF。--工具人樂然 ✉ 編織希冀,寄於歌聲。 2021年7月28日 (三) 18:06 (CST)
- ( ¡ )題外話 那攻擊者還可能找到嗎?--布洛肯亞雷的反銻研究所(研究成果/找他一同研究) 2021年7月28日 (三) 18:10 (CST)
- 事實上沒有人知道。就算是最近,在WAF強度大幅提升的情況下,我們還發現了一個在頁面內埋惡意代碼的用戶。我只能說,近期內應該不會有撤銷WAF的打算。--工具人樂然 ✉ 編織希冀,寄於歌聲。 2021年7月28日 (三) 18:13 (CST)
- ( ¡ )題外話 那攻擊者還可能找到嗎?--布洛肯亞雷的反銻研究所(研究成果/找他一同研究) 2021年7月28日 (三) 18:10 (CST)
- 站在我個人的角度說,我認為開放這件事情本身也不現實,畢竟我們不知道誰是攻擊者。目前只能通過儘量限制請求數量等手段預防WAF。--工具人樂然 ✉ 編織希冀,寄於歌聲。 2021年7月28日 (三) 18:06 (CST)
- 活躍編輯的常用IP並不意味著不是攻擊者的IP,畢竟出口IP並不是和機子一一對應的。不過話說回來,有沒有什麼辦法評估一下放開活躍編輯的常用IP到底會有多大的可能性導致把攻擊放進來呢?……大概沒什麼好辦法…… ——拒絕互膜的
M. J. H. 【蠱】{{#forargs:}} is evil! 2021年7月28日 (三) 18:08 (CST)- (&)建議 可以主動申請,而且申請者必須是優編甚至維護組成員。--北湖3(討論) 2021年7月28日 (三) 18:11 (CST)
- 申請者是什麼和同一IP的其他用戶是什麼並不相關,所以這樣的限制恐怕也無法解決問題。——拒絕互膜的
M. J. H. 【豫】{{#forargs:}} is evil! 2021年7月28日 (三) 18:13 (CST) - 動態IP分配申請了也是白瞎。——飯糰人 一位史蒂夫 (討論·貢獻)✉❶ 請問您要單推一隻小浣熊嗎? 2021年7月28日 (三) 18:14 (CST)
- 這件事不是權限體系能夠決定的。先不說「攻擊者竟在我身邊」這種極端情況,如MJH所說,按照用戶判斷IP不可靠,這是IP封禁給我們的教訓。--工具人樂然 ✉ 編織希冀,寄於歌聲。 2021年7月28日 (三) 18:15 (CST)
- 申請者是什麼和同一IP的其他用戶是什麼並不相關,所以這樣的限制恐怕也無法解決問題。——拒絕互膜的
- (&)建議 可以主動申請,而且申請者必須是優編甚至維護組成員。--北湖3(討論) 2021年7月28日 (三) 18:11 (CST)
建議使用移動版,可有效緩解waf帶來的問題。—— ほしみ 2021年7月28日 (三) 19:46 (CST)
- (-)弱反對 我都用電腦了不就是為了解決web版的一系列固有缺陷的嗎?
請不要說這種「老鼠給貓掛鈴鐺」式的「正確的廢話」--北湖3(討論) 2021年7月28日 (三) 20:01 (CST)- 那麼這裡可能您只能進行取捨了,或是如前面其他人所說,自行更換ip。—— ほしみ 2021年7月28日 (三) 20:08 (CST)
- 「web版」這個說法有點奇怪…… ——拒絕互膜的
M. J. H. 【離】{{#forargs:}} is evil! 2021年7月29日 (四) 09:21 (CST)
求助:navbox怎麼實現自動摺疊啊———DARKNESSⓄ討論 2021年7月29日 (四) 20:12 (CST)
- @DARKNESS117 可以使用{{Navbox}}的
state
參數:|state = {{#ifeq:{{{1}}}|collapsed|mw-collapsible mw-collapsed|mw-uncollapsed}}
,調用模板時使用{{模板名称|collapsed}}
即可摺疊。 - —— GuoPC「昨日より 明日より 今を作り出そう!」 2021年7月29日 (四) 20:26 (CST)
- 請問具體是什麼navbox呢?——飯糰人 一位史蒂夫 (討論·貢獻)✉❶ 請問您要單推一隻小浣熊嗎? 2021年7月29日 (四) 20:27 (CST)
謝謝,問題已經解決了———DARKNESSⓄ討論 2021年7月29日 (四) 22:17 (CST)DARKNESS117
關於本站搜索
在站點內所有頁面右上角的搜索框中搜索以「#」開頭的字符時不會開始搜索,而是連結到類似https://zh.moegirl.org.cn/Mainpage#***的頁面中,是屬於本站在使用過程中導致的問題還是MediaWiki本身問題,能否解決?--來自NE-Fengyun(我的討論頁) 2021年7月28日 (三) 18:30 (CST)
- 老問題了吧……(MW出來挨打)——飯糰人 一位史蒂夫 (討論·貢獻)✉❶ 請問您要單推一隻小浣熊嗎? 2021年7月28日 (三) 18:31 (CST)
- 不是bug,是特性(—— ほしみ 2021年7月28日 (三) 18:58 (CST)
- 試了一下在搜索內容內容前加
~
(即搜索~#XXX
)的方法依然可以強制搜索(參見Help:高級搜索#符號),不過搜索結果似乎和「#」無關。話說回來是什麼需求需要搜索「#」開頭?——C8H17OH(討論) 2021年7月28日 (三) 20:21 (CST)
- 不是bug,是彩蛋(——新たな世界を見せてあげよう!(討論) 2021年7月29日 (四) 15:19 (CST)
關於Template:歡迎的一系列問題
去年2月,User:850710247liu創建了與{{welcome}}類似的{{歡迎}},但此模板存在較為嚴重的問題,故在此發起討論停用或改進此模板。
- 此模板創建者擅自調用了only for Help:沙盒/首頁的widget:沙盒/首頁;
- 此模板內置{{目錄右置}},且會強顯目錄,相當於排版他人討論頁,違反MGP:討論區管理方針之規定;
- 此模板在MacOS Chrome等瀏覽器下,屏幕顯示比例為100%(大於85%)時出現排版異常,超出界面,造成了較差的用戶體驗,多人可穩定復現此問題。
—— ほしみ 2021年8月5日 (四) 12:46 (CST)
- 針對第三條問題,我可以復現。我認為如果只是希望調用相關CSS,應使用templatestyles而非調用整個widget。並且除開margin,模板所帶來的其他排版問題(例如float等)也使我認為重構該模板會比較合理。--EnMGP編輯者樂然 ✉ 編織希冀,寄於歌聲。 2021年8月5日 (四) 12:56 (CST)
這個模板有點老了,我都快忘了,而且已經有新代碼了,我一直沒弄過來,晚上我試著改上去重構一下吧。--悠遠的蒼穹 (Talk with me!) 2021年8月5日 (四) 13:12 (CST)
- 此模板嵌入較多,最好先在沙盒進行測試,以免修改後再次違反MGP:討論區管理方針之規定哈。—— ほしみ 2021年8月5日 (四) 13:36 (CST)
- 感謝提醒--悠遠的蒼穹 (Talk with me!) 2021年8月5日 (四) 15:28 (CST)
完成,萌百部分頁面可能還有緩存,刷新成最新頁面就可以看到上面三個問題已經全部解決,模板重構完成--悠遠的蒼穹 (Talk with me!) 2021年8月5日 (四) 16:19 (CST)
JaMGP Help
Hello. The character page on Japanese Moegirlpedia has an error... the birthday and zodiac sections are not being displayed correctly because there is an error inside the Lua Module. LiaMinina(討論) 2021年8月5日 (四) 22:47 (CST)
- @LiaMinina I've temporarily fixed the problem, the parameter "誕生日" (birthday) should be in "Nov. 17" format, and "星座" (zodiac) should be in "{{Astrology|11|17}}" or "さそり座" format. -- GuoPC ☕ 📝 2021年8月6日 (五) 08:39 (CST)
- @GuoPC Okay, I've set the parameters. It looks good so far, thank you!
LiaMinina(討論) 2021年8月7日 (六) 20:46 (CST)
關於在div中使用background-image的問題
目前CSS屬性background-image
還是處於被封禁狀態。
這個東西還是很常用的,如果配合其它的background-
開頭的屬性可以做出很多以前需要用各種絕對定位和相對定位才能做到的效果。我能理解封禁是出於跨站請求不安全的因素,那是否能將連結限制在共享站以內,只在參數提供文件名,用{{filepath:...}}
來獲取連結?
既然模板空間和主空間都無法使用的話,Widget空間可不可以?-- printf("Hello, world!\n");
(查 · 論 · 編) 2021年8月7日 (六) 17:05 (CST)
- Widget可以寫純HTML,當然可以。--Func(討論·貢獻) 2021年8月7日 (六) 17:10 (CST)
- 近期有做這個的計畫嗎?--
NSLog(@"Hello, World!");
(查 · 論 · 編) 2021年8月7日 (六) 17:22 (CST)
- 近期有做這個的計畫嗎?--
<templatestyles src="..." />
—— Ant 1597 { 論 | 獻 | 志 } (回覆時請@我
, 感謝.) 2021年8月7日 (六) 17:21 (CST)- 要通用的模板。--
writeln('Hello, world!');
(查 · 論 · 編) 2021年8月7日 (六) 17:25 (CST)- 嗯,模板樣式表只能通過選擇器和靜態
url(...)
實現,屬於權宜之計。如果要靠正文代碼中的輸入 URL 來渲染背景的話,只能考慮使用 Widget 製作模板或者更改 sanitizer 規則了。—— Ant 1597 { 論 | 獻 | 志 } (回覆時請@我
, 感謝.) 2021年8月7日 (六) 17:33 (CST) - Templatestyles可以在後台白名單url地址,我記得運維之前已經改過了。inline的我目前還沒找到相關文檔,不知道有沒有方法能夠直接介入伺服器端的sanitise過程……--酒姬民樂然 ✉ 編織希冀,寄於歌聲。 2021年8月7日 (六) 17:34 (CST)
- 看來url是hardcode在sanitizer里了。這樣的話可能只能靠widget實現……--OIer樂然 ✉ 編織希冀,寄於歌聲。 2021年8月7日 (六) 17:40 (CST)
- 嗯,模板樣式表只能通過選擇器和靜態
- 要通用的模板。--
Widget擴展由於和新版本MW兼容性不好,站內大多Widget得改版,到時候是否會繼續使用該擴展還不可知。(雖然升級事宜還沒有看到跡象()--Func(討論·貢獻) 2021年8月7日 (六) 17:53 (CST)
- 那我先寫一個吧,升級那是以後的事,到時候再解決。
寫好了at你。--disp('hello world!')
(查 · 論 · 編) 2021年8月7日 (六) 18:00 (CST)
Widget_talk:背景圖片區域 試做了一個,等通過。-- Transcript show: 'Hello, world!'
(查 · 論 · 編) 2021年8月7日 (六) 20:49 (CST)
- 撤銷請求吧,我找到了另一種不用Widget就可以實現的安全方法,已經做成同名模板了。--
PRINT "Hello, world!"
(查 · 論 · 編) 2021年8月7日 (六) 23:25 (CST)
關於引號的轉換
繁體的「」、『』與簡體的“”、‘’是對應關係,但是在萌百好像不會正確轉換,是有什麼原因嗎?—— Eric Liu(留言) 2021年8月3日 (二) 12:11 (CST)
- 日語的『』除了當單引號‘’用,還用作書名號《》。不知道和這個有沒有關係。▘▗ ▚ あめろ 討論 2021年8月3日 (二) 12:37 (CST)
- 除日語中使用外,在內地,按現行GB/T 15834-2011《標點符號用法》,直角引號也屬於規範符號,常用於豎排文本。—— ほしみ 2021年8月3日 (二) 12:40 (CST)
希望引入維基百科的大字體小工具
比較在世面上流行的主要網站,萌娘百科條目正文的字號似乎有點小了,尤其是在長篇條目中,小字號比較費眼睛,可能會使部分用戶在閱讀時產生疲憊感,建議引入維基百科的大字體小工具([1]),這個工具使維基百科條目正文的字號保持在了0.938rem。--悠遠的蒼穹 (Talk with me!) 2021年8月5日 (四) 09:47 (CST)
- @AnnAngela--悠遠的蒼穹 (Talk with me!) 2021年8月5日 (四) 10:06 (CST)
- 不論是Chrome還是Firefox都均有縮放功能,都可以按照不同域名分別設置縮放大小。_USER:YOONHA~1.PAR(留言)2021年8月5日(木)11:39:58(JST)
- (▲)如YOONHA~1.PAR所述,沒有必要,也無需默認開啟,看不清的人可以自行放大或寫入個人css。以及,editfont的13px和大字號的13.936px也沒差多少吧。—— ほしみ 2021年8月5日 (四) 10:52 (CST)
- 姑且問一句你是否知道「em」這個單位是什麼意思。 ——拒絕互膜的
M. J. H. 【大壯】{{#forargs:}} is evil! 2021年8月5日 (四) 10:55 (CST)- 是可以手動調的,但用戶從其他網站第一次進入本站可能就會有一種電腦突然變大了的突兀感。。。--悠遠的蒼穹 (Talk with me!) 2021年8月5日 (四) 11:05 (CST)
- 大小劇烈變化的插入,可能會使視覺信號受到一定程度上的刺激,間斷用戶的網絡沉浸式體驗--悠遠的蒼穹 (Talk with me!) 2021年8月5日 (四) 11:09 (CST)
It's super 新名詞兒 time!用戶的網絡沉浸式體驗
- 不過,Maya看了看自己現在打開著的幾個網站,bilibili評論區字號是14px,必應搜索結果的字號是13px,所以姑且好奇一下您說的「在世面上流行的主要網站」是什麼。 ——拒絕互膜的
M. J. H. 【頤】{{#forargs:}} is evil! 2021年8月5日 (四) 11:21 (CST)
- 大小劇烈變化的插入,可能會使視覺信號受到一定程度上的刺激,間斷用戶的網絡沉浸式體驗--悠遠的蒼穹 (Talk with me!) 2021年8月5日 (四) 11:09 (CST)
- 是可以手動調的,但用戶從其他網站第一次進入本站可能就會有一種電腦突然變大了的突兀感。。。--悠遠的蒼穹 (Talk with me!) 2021年8月5日 (四) 11:05 (CST)
- 但是,萌百字號的確挺小的,可以對比知乎這個主流且文字為主的網站以及B站的文章區(不是瑪雅說的評論區)。況且這邊瀏覽器的縮放默認情況下會把非文字的部分也放大,造成排版比例失調。要改的話應該直接修改全站CSS,這個小工具應該還是要註冊了才能用,對於挽救瀏覽者「這個網站字體好小」的印象沒有效用。
反正我這邊早就自己修CSS把字調大了,去掉自己的CSS就真的覺得字好小。——🗨iehcni 2021年8月5日 (四) 11:26 (CST)- 知乎是15px,大不了太多。bilibili文章區倒是確實,有17px。——拒絕互膜的
M. J. H. 【益】{{#forargs:}} is evil! 2021年8月5日 (四) 11:30 (CST) - (況且如果要討論「用戶的網絡沉浸式體驗」,該考慮的不是「什麼網站與萌百定位相似」,而是「什麼網站更容易有到萌百的連結」。)——拒絕互膜的
M. J. H. 【否】{{#forargs:}} is evil! 2021年8月5日 (四) 11:34 (CST)- 這工具本來就只改條目正文,其他不改的。。你和別的站點評論字號比啥。。。。。要比的得是頁面主體呀,而且這玩意用眼睛都能看出來誰打誰小。。。。。。--悠遠的蒼穹 (Talk with me!) 2021年8月5日 (四) 11:40 (CST)
- 上面縮進有問題,失禮了。我的眼睛是覺得15px這個大小和13px比起來看得舒服多了
其實也算是自己的癖好,畢竟我看班固米、s1也覺得字太小,不是對萌百一個網站有這個感覺……當然相信這種字號落差對用戶體驗的影響不會有多嚴重,當初我也是覺得字號太小但仍然進來了。——🗨iehcni 2021年8月5日 (四) 11:44 (CST)
- 知乎是15px,大不了太多。bilibili文章區倒是確實,有17px。——拒絕互膜的
要什麼大字體小工具,瀏覽器的縮放功能是幹什麼用的?--希望のはな 繋いだ絆を (不要停下來啊!) 2021年8月5日 (四) 11:31 (CST)
- 用戶第一次訪問呢--悠遠的蒼穹 (Talk with me!) 2021年8月5日 (四) 11:40 (CST)
- 不過使用縮放確實是個好辦法,整個頁面都會變大。挺舒服的。但我覺得可能會有新用戶不會?--悠遠的蒼穹 (Talk with me!) 2021年8月5日 (四) 12:17 (CST)
- 還是得用實踐說話。以你的立場,不妨用其他無關網站測試一下能否通過把字號改大增加用戶回頭率。 ——拒絕互膜的
M. J. H. 【中孚】{{#forargs:}} is evil! 2021年8月5日 (四) 11:44 (CST)- 字號和回頭率有什麼關係???角度清奇。這玩意不是增加用戶體驗的嗎。咱能不能稍微問點正常點的問題,你這問的都是什麼跟什麼呀。。。我已經不想再回答你了。--悠遠的蒼穹 (Talk with me!) 2021年8月5日 (四) 12:09 (CST)
- (▲)同YOONHA~1.PAR我認為沒什麼太大的必要。
我看不懂,但我大受震撼。——小奶糊 一位史蒂夫 (討論·貢獻)✉❶ 請問您要單推一隻小浣熊嗎? 2021年8月5日 (四) 17:05 (CST) - 工具引進字號不變就妥協了嘛(--這個人,曾想拯救黎明 2021年8月5日 (四) 20:29 (CST)
是這樣的:這幾天我正想搬運滾動的天空Wiki的導航框來萌百並被@屠麟傲血阻止,計畫中和幾個版本的Navbox對比如下:
項目 | T:大家族模板 | Module:Nav | 滾維導航框 | 我計畫搬運的 |
---|---|---|---|---|
無窮行數 | 不支持 | 支持 | 支持 | 支持 |
原生子框 | 不支持 | 不支持 | 支持 | 支持 |
無限層級 | - | - | 支持 | 支持 |
樣式優化 | 未優化 | 未優化 | 有優化 | 計畫不優化 |
傳統方法 | 支持 | 支持 | 使用Luaon | 使用Luaon |
資源耗用 | 較高 | 較低 | 低 | 低 |
註解:
滾動的天空Wiki版本navbox主要由站長用戶:SolidBlock設計。我在本討論串內使用了templatestyles(直接引自滾動的天空Wiki,現在User:佳沛降解劑/沙盒/Navbox/style.css)。因為mw-parser-output的限制,部分CSS未生效。
我在搬運版用的navbar是維基百科版本的。
- 原生子框
- 指直接通過一個導航框模板實現其內部的子導航框。在傳統方法中,僅支持將第一個參數設置為child。
- 無限層級
- 指原生子框的堆疊層級。(之前滾維僅支持3級)
- 樣式優化
- 在滾維版本的導航框,默認的樣式全部置於小工具中;其一個表格就是一個表格,一個單元格就是一個單元格,不存在單獨的單元格tr style="height:2px;"實現間隙,也不區分外框表和內框表。為了確保美觀,該版本單元格之間的間隙是通過透明的邊界(border)實現的,並且設置了background-clip:padding-box !important;,以防止單元格背景延伸到間隙內。詳見https://rs.miraheze.org/wiki/Module:navbox/doc。
- 傳統方法
- 指將第一個參數設為child以實現子導航框的用法。在滾動的天空Wiki和我搬運的版本,子導航框生成數據後會傳入根導航框,依然由根導航框渲染。(此項目是我開發的)
- Luaon
Lua Object Notation。以Lua表定義格式為基礎類似於JSON的標記語言。(此項目由我開發)
問題就出在樣式優化這一點,奈何我開始著手才真正體會到「沒有對比就沒有傷害」。
誰收到了傷害?是萌百的Navbox嗎?不,是我。
是我看到了萌百Navbox才真正領會到SolidBlock的CSS技藝之高深,真正領會到萌百導航框的差距,因而認為我不配搬運CSS。尤其是單元格內部文字的邊距設定,滾維版本直接設置padding(帶有子導航框的列表不設置),而萌百版本是用了有margin的div,在子導航框時再關掉。這樣子是相當累贅的。作為八分之一個對「將一對標籤拆散放在兩個模板中」的行為深惡痛疾的猴子,這也成為了我不想繼續搬運的原因。Z E S 2021年8月4日 (三) 21:36 (CST)
foo 是不是沒有這個group右邊的東西會全部中對齊? bar foo bar Arc Phi cytus Geometry Dash Rizline Foo bar 我 包 我 自 己 我 自 己 是不是沒有這個group右邊的東西會全部中對齊? bar foo bar Arc Phi cytus Geometry Dash Rizline Foo bar
頁面User:佳沛降解劑/沙盒/Navbox/style.css沒有內容。 補充一下用例,大家可以看看代碼。Z E S 2021年8月4日 (三) 21:45 (CST)
- ( ¿ ) 喵喵喵? 所以您想要幹什麼?——東方眾 一位史蒂夫 (討論·貢獻)✉❶ 請問您要單推一隻小浣熊嗎? 2021年8月4日 (三) 21:59 (CST)
- 他想要優化{{Navbox}}。▘▗ ▚ あめろ 討論 2021年8月4日 (三) 22:48 (CST)
- 其實只是遇到一些技術相關事情來訴說一下(話說您詳細地讀了嗎(Z E S 2021年8月4日 (三) 22:53 (CST)
- 問的我嗎?我本來以為我詳細讀了,你這樣一問,我覺得我可能沒理解你的意思。所以樣式還優化嗎?▘▗ ▚ あめろ 討論 2021年8月4日 (三) 23:09 (CST)
- 我讀了,並且我大受震撼。特別是您那句「誰收到了傷害?是萌百的Navbox嗎?不,是我。」簡直震懾到了我。——巡查姬 一位史蒂夫 (討論·貢獻)✉❶ 請問您要單推一隻小浣熊嗎? 2021年8月4日 (三) 23:40 (CST)
- 有趣的是,本版其他所有人似乎都注意到了本版是「Project talk:討論版」而不是「Project talk:訴說版」。 ——拒絕互膜的
M. J. H. 【坤】{{#forargs:}} is evil! 2021年8月5日 (四) 10:53 (CST)
- 其實只是遇到一些技術相關事情來訴說一下(話說您詳細地讀了嗎(Z E S 2021年8月4日 (三) 22:53 (CST)
- 他想要優化{{Navbox}}。▘▗ ▚ あめろ 討論 2021年8月4日 (三) 22:48 (CST)
- 我大概了解了,你說的這個確實是有優勢的,就解決站內常見痛點來說,大概有減少展開長度和能夠真正實現奇偶行顏色兩點。但是這個版本看起來無法簡單適配站內的引用,並且我對所謂『Luaon』的實現的穩定性存在疑慮。另外你這個搬運,可能CC協議並不兼容。--Func(討論·貢獻) 2021年8月4日 (三) 23:15 (CST)
- 按當前伺服器情況,我比較擔心的是這種核心模板模塊化後Lua性能的問題(尤其是超時)
,當然目前來看展開長度限制確實也比較蛋疼--EnMGP編輯者樂然 ✉ 編織希冀,寄於歌聲。 2021年8月5日 (四) 00:01 (CST) - @杨哲思
關於CSS我有個建議:column-span這條屬性在Firefox Android上不會默認開啟,需要設法替代。希望有安卓用戶能幫忙測試一下當前的實際效果如何。 - 我想問下這個column-span是幹嘛的?這根本就不是用於<table>的樣式吧?——移動版用戶 Bhsd 2021年8月5日 (四) 00:47 (CST)
再解釋一下,在下本意是,有一個具有多方面優勢的導航框,在滾動的天空Wiki(我也參與了滾動的天空Wiki導航框的修訂),我參考滾動的天空Wiki版本設計了一個(其實沒什麼區別),現在我在疑慮要不要搬運CSS。如果我搬運的話,我感到我不配,並且版權兼容性(滾維使用CC BY-NC-SA 4.0)似乎也是一個問題滾維的東西當然可以搬,滾維的navbox也參考了維百的說是參考罷了樣式要放到小工具里,顏色和字號還要改一改。如果我不搬運CSS,仍然用萌百的,那我就會為沒有本版本Navbox最大的優勢而感到可惜(?,並且這樣子模塊代碼也要改,我覺得很麻煩,不是很想改(Z E S 2021年8月5日 (四) 12:39 (CST)
- 我直說吧,和Func[更多]大佬討論後明白了這個模塊確實有明顯改進的地方。但這個CSS水準也就中規中矩吧。——移動版用戶 Bhsd 2021年8月5日 (四) 13:56 (CST)
- ?是嗎?我覺得CSS才是最精華的部分之一。但是這CSS是User:SolidBlock寫的( Z E S 2021年8月5日 (四) 17:37 (CST)
- 呃,一會兒說這個CSS是最大的優勢,一會兒說這個CSS「說是」參考維百,到底是改了很多,還是沒改多少?然後還說搬運沒關係,所以為什麼不搬運CSS?
而且你應該還和滾維站長認識,和他商量一下,小改一下再搬不是很好嗎?如果的確效果好,那不是皆大歡喜?——💬iehcni 2021年8月5日 (四) 20:24 (CST)
暫時先咕掉(Z E S 2021年8月6日 (五) 12:06 (CST)
- ZES提到的這個Luaon,我去看了看,似乎是為了實現表與字符串之間的轉換從而實現在維基文本層面的參數傳遞,但效果似乎並不好。而且還是存在一些不足之處,比如
將字符串編碼的代碼是。又如,tovalue函數中,使用了string.format("'%s'",value)
,顯然如果涉及轉義則會出現問題%d
來判斷是否為數字,但%d
似乎只能識別數字,不能夠識別負數以及inf、nan等特殊數字(雖然說用在navbox中也不太可能)。而且,在表和字符串之間轉換,這一過程本來就是比較耗費性能的。滾動的天空Wiki上的navbox也是支持傳統的定義子導航框的方式的,不必使用Luaon。
前面有人提到了column-span,應該是用於分欄文本的,不適用於表格,也不能接數字。此外templatestyles不能識別.skin-minerva
的問題,可以嘗試改成body.skin-minerva
。--SolidBlock(討論) 2021年8月6日 (五) 18:43 (CST)
- @SolidBlock 萌百的templatestyles版本不支持
body.skin-minerva
。——移動版用戶 Bhsd 2021年8月6日 (五) 22:52 (CST)
- @SolidBlock 萌百的templatestyles版本不支持
- 不是不支持,是都不支持,因為模板樣式的每一個選擇器都會被MW加上.mw-parser-output,以防止用戶修改其他部分(Z E S 2021年8月7日 (六) 12:22 (CST)
- @杨哲思 你自己看吧:mw:extension:templateStyles#Caveats ——移動版用戶 Bhsd 2021年8月7日 (六) 12:57 (CST)
- 鄉愁是一堵厚厚的防火牆我在這頭MW官網在那頭(Z E S 2021年8月7日 (六) 13:30 (CST)
- @杨哲思:以下內容摘自mw官網:
- To target styles based on skins, use a selector such as
body.skin-vector .myClass
; specification of thebody
element is required and must be followed by a descendant combinator (i.e. the space). - Other classes on the
body
orhtml
elements may be targeted in the same manner. - ——SolidBlock(討論) 2021年8月7日 (六) 14:15 (CST)
- 善用bing搜索結果緩存頁可以繞過牆看到mw文檔。 ——拒絕互膜的
M. J. H. 【無妄】{{#forargs:}} is evil! 2021年8月7日 (六) 14:30 (CST)
恕我直言,使用Luaon並不是一個很好的包裝傳參的解決方案。
- Luaon將模塊從頁面中接收到的調用參數Lua表(內容是「能接收Unicode字符並且自身就由很多轉義功能代碼的維基文本」)轉化為「能接受Unicode字符並且擁有另一套轉義規則的自定義結構的字符串」,隨後將這個字符串從模塊中傳出,經由維基文本層面再度作為參數傳入,在上級Navbox的解析過程中再度還原成「一個Lua表」。在此過程中頻繁的Lua模塊調用以及字符串的增、刪、匹配、格式化、轉義等操作帶來了大量的不必要性能損失,另外對兩套轉義規則之間的轉換代碼也會引入一些不穩定的因素(你永遠不知道什麼時候會出BUG)。
- Luaon從這名字上就可以看出設計者是模仿JSON的格式進行構建的,那麼我們為什麼不直接使用現成的成熟解決方案呢?萌百又不是不支持JSON。包括MediaWiki都提供了一個接口叫做mw.text.jsonDecode專供Lua模塊解析JSON字符串。
- 我之前也和@Func聊到過,在目前越來越多的大家族模板不得不需要從模板換成模塊來續命的背景下,由於Navbox的對外接口不能改變,因此優化只有兩條路可以走了。
- 第一條路是HTML/CSS,但前端的東西我都不懂,只能將希望寄托在懂的大佬身上,能否設計出更簡潔但更靈活強大的樣式。
- 另一條路就是後端,我個人認為目前從模板轉到模塊的思路是正確的,那麼問題就是如何設計出大家族模板中數據的編寫、儲存和讀取的方式。
- 站內有一個領域叫做「字詞轉換」,每個字詞轉換的資料庫以模塊的形式放在模塊:CGroup的子頁面下,而將其可視化的是一個默默無聞地工作著的模板{{CGroupViewer}},它的代碼很簡單,就是讀取字詞轉換的資料庫並將其解析成wikitext,這給了我靈感。我個人也用模塊搭建過不少資料庫,綜合用下來Lua的語法還是過於複雜,對於初次接觸的編輯者來說學習成本過大。那麼有沒有什麼格式比Lua更簡潔,也貼近模板的「參數名/參數值」結構呢?我將目光看向了JSON。
- 我的想法是,將大家族模板中的數據寫在一個JSON頁面中,這樣一來Nav只需要充當一個Parser或者說是Viewer的角色,將兩者完全脫鉤。
- 觀察Luaon的作用原理,用戶先在維基文本里寫數據→數據傳入模塊→模塊將數據處理成自定義結構的字符串→模塊將數據傳出到維基文本→數據作為上層模塊的參數傳入……,不難看到此間維基層面和模塊層面經歷太多數據交換,而作為Parser或Viewer的Nav模塊將不用,只要傳入頁面的地址,所有數據處理完全在模塊中進行,直到輸出結果都不會受到任何干擾。
- 對於常見的大box套小box,小box套更小box的情況同樣可以輕鬆處理,只要我們規定一個結構,比如說
"list1": { "linkto": "XXXX/YYYY" }
,那麼模塊讀取到這個結構時,就會把XXXX/YYYY
視為子navbox的頁面地址,讀取其中的內容,然後搭建嵌套結構。
因此我也可以列一個表格
項目 | 模板:Navbox | 模塊:Nav | 我設想的方案 |
---|---|---|---|
無窮行數 | 不支持 | 支持 | 支持 |
奇偶樣式 | 手動調節 | 自動/手動調節[1] | 自動調節為主 |
原生子框 | 不支持 | 不支持 | 棄用 |
縮進和代碼高亮 | 不支持/SyntaxHightlight插件 | 不支持/SyntaxHightlight插件 | 原生編輯器 |
向下兼容[2] | 支持 | 支持 | 支持(模塊判斷頁面內容模型) |
一套三需加載頁面數[3] | 4 | 5 | 5 |
頁面緩存[4] | 重用 | 重用 | 重用 |
編輯者需要掌握 | wikitext | wikitext | JSON基礎語法&wikitext |
潛在問題 | 展開超限 | 優化23%~27%[5]後展開超限 | Lua超時(7秒) |
- 注釋:
- ↑ 目前模塊:Nav自動判斷奇偶的邏輯是分析同層級的上一個list中出現的最後一個tr標籤的class是even還是odd,因此某些時候能正常工作,某些時候不會。
- ↑ 保留現有的所有參數名稱、功能不變;使用新方案構建的Navbox可以直接引用已有的舊Navbox。
- ↑ 「一套三」指的是一個總Navbox套三個子Navbox。內容分別都寫在各自的頁面中的前提下,模板加載總Navbox然後加載子Navbox,共4個頁面;模塊比模板多加載了模塊頁面,共5個頁面。
- ↑ MediaWiki解析器在第一次加載一個現存的頁面後,會在內存中保留它直到整個頁面都解析完畢。理論上藉助模塊來加載並解析頁面將不會吃到這個福利,不過我們可以在模塊中緩存這個結果:在遍歷所有linkto結構時,遇到新的頁面則加載它並存儲下來,遇到已經緩存的頁面則直接用存儲的結果進行處理。
- ↑ 萌娘百科_talk:討論版/技術實現/存檔/2020年05月#請求將{{Navbox_subgroup}}模塊化,討論中我給出過實測數據,兩個大家族模板模塊化後,展開大小優化23%~27%,模板參數大小優化55%~64%。
唯二讓我慎重考慮這個新方案的問題是編輯者需要學習一種新的格式,以及模塊永遠繞不過去的弊病(Lua超時),不過我相信,這個新方案的提出作為拋磚引玉,一定會開拓社群的思路,為優化Navbox的事業添上一把火。--サンムル(討論) 2021年8月7日 (六) 15:33 (CST)
@サンムル,因為JSON不支持字符串和數字鍵共存。Z E S 2021年8月7日 (六) 16:46 (CST)
關於「發」的繁簡轉換
今天發現U:Sakutaro Takizawa手動替換了一部分「發」的轉換(雖然由於替換方式錯誤而被回退了),就此問題前來詢問一下:
目前「生发」會被固定轉換為「生髮」,但若是出現一個以「生」結尾的人名後加「發現」「發明」「發覺」「發誓」「發起」等動詞時就會出現錯誤轉換。考慮到這種情況可能有很多(以U:Sakutaro Takizawa的貢獻來估計),是否有必要修改轉換列表?——△AKQ 代號 不可逆(Talk) 2021年8月13日 (五) 23:15 (CST)
- 這個轉換已經在新的維基百科轉換表中修復,只有
生发x=>生髮x
這種轉換了,但萌百什麼時候能升級系統,只能說無可奉告。另外,似乎生髮和生發在萌百都有存在,這件事還有點難辦。—— 屠麟傲血(討論) 2021年8月13日 (五) 23:23 (CST)
如何在div縮小到一定寬度後自動出現滾動條?
Template:NoWorld這個模板的寬度是設置了vw自適應的,而裡面的頭像的尺寸則不會改變,所以當窗口寬度小於768px後裡面的頭像就會寬於模板然後就有一部分看不見了。
所以雖然沒有什麼用(真的會有人用768p以下的設備看萌百嗎),但我想問問有沒有什麼辦法可以在模板寬度縮小到一定寬度比如768px以下就出現滾動條,而模板寬度在768px以上時仍然是overflow:hidden?
用js肯定可以比較方便地實現這個功能,但是萌百用js很不方便,所以沒法考慮。——我是亙古輪迴Colby,2 0 5 3 / 0 8 2 3 / 2 9 7 0 / 2 7 9 9 / 5 0 4 2 /。 2021年8月13日 (五) 22:45 (CST)
- 縮小到800px自動出現滾動條。你看看
- あめろ 討論 2021年8月13日 (五) 22:52 (CST)
- 謝謝,這個方法很巧妙。——我是亙古輪迴Colby,2 0 5 3 / 0 8 2 3 / 2 9 7 0 / 2 7 9 9 / 5 0 4 2 /。 2021年8月13日 (五) 23:11 (CST)
- 但是因為grid嵌套的問題overflow不能正常使用。——我是亙古輪迴Colby,2 0 5 3 / 0 8 2 3 / 2 9 7 0 / 2 7 9 9 / 5 0 4 2 /。 2021年8月13日 (五) 23:54 (CST)
- 我看了你的沙盒,不是grid嵌套的問題,而是你overflow屬性添加錯位置了。你介不介意我編輯你的沙盒?我幫你改一下。 あめろ 討論 2021年8月14日 (六) 00:09 (CST)
- @あめろ沒問題,請隨意修改。不過現在保存的本來就是故意留下的錯誤版本(用來做其他實驗),正確的版本並未保存。——我是亙古輪迴Colby,2 0 5 3 / 0 8 2 3 / 2 9 7 0 / 2 7 9 9 / 5 0 4 2 /。 2021年8月14日 (六) 19:30 (CST)
- @あめろ謝謝,這樣確實沒問題。不過這樣就是用絕對定位代替grid定位,如果以後有人要修改(尤其是大改)的話就不大友好,我是考慮到這點所以才一直沒有用絕對定位。另外.membersinnoworld:hover ~.noworldcover是目前我能想出來的唯一一個可以實現那個蓋住其他頭像功能的方法,因此我無法把div移到標記處,不知道你有沒有什麼其他的好辦法。綜上所述這個問題並未解決,不過謝謝你的修改讓我拓寬了思路。——我是亙古輪迴Colby,2 0 5 3 / 0 8 2 3 / 2 9 7 0 / 2 7 9 9 / 5 0 4 2 /。 2021年8月15日 (日) 08:58 (CST)
- @あめろ沒問題,請隨意修改。不過現在保存的本來就是故意留下的錯誤版本(用來做其他實驗),正確的版本並未保存。——我是亙古輪迴Colby,2 0 5 3 / 0 8 2 3 / 2 9 7 0 / 2 7 9 9 / 5 0 4 2 /。 2021年8月14日 (六) 19:30 (CST)
- 我看了你的沙盒,不是grid嵌套的問題,而是你overflow屬性添加錯位置了。你介不介意我編輯你的沙盒?我幫你改一下。 あめろ 討論 2021年8月14日 (六) 00:09 (CST)
- 但是因為grid嵌套的問題overflow不能正常使用。——我是亙古輪迴Colby,2 0 5 3 / 0 8 2 3 / 2 9 7 0 / 2 7 9 9 / 5 0 4 2 /。 2021年8月13日 (五) 23:54 (CST)
- 謝謝,這個方法很巧妙。——我是亙古輪迴Colby,2 0 5 3 / 0 8 2 3 / 2 9 7 0 / 2 7 9 9 / 5 0 4 2 /。 2021年8月13日 (五) 23:11 (CST)
( ¡ )題外話 可否不要用vw單位,我這裡限制了mw-content-text的最大寬度,你用vw的話在我這裡實際上是超出內容頁面了 あめろ 討論 2021年8月13日 (五) 22:57 (CST)
- 很抱歉不能改,為了兼容性和自適應我只能這樣做,目前我還沒有想到其他更好的辦法。——我是亙古輪迴Colby,2 0 5 3 / 0 8 2 3 / 2 9 7 0 / 2 7 9 9 / 5 0 4 2 /。 2021年8月13日 (五) 23:11 (CST)
能否在條目內使用滾動條
能否將全站公告的滾動條(scrollDiv)進行推廣,將僅用於這個id改為用於一個類?--Z E S 2021年8月9日 (一) 21:42 (CST)
- 如果不需要模板化的話,建議考慮CSS動畫,示例見special:permalink/5120834。——移動版用戶 Bhsd 2021年8月10日 (二) 04:02 (CST)
- {{滾動條}}。 ——拒絕互膜的
M. J. H. 【睽】{{#forargs:}} is evil! 2021年8月12日 (四) 09:03 (CST)