User Details
- User Since
- Oct 13 2020, 8:45 AM (128 w, 1 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- LuciferianThomas [ Global Accounts ]
Jan 20 2023
The main problem is when this happens with VE options, VE won't load at all, essentially bricking the options (options can only be changed when VE is loaded), leaving the API as the only way to fix things.
Jan 16 2023
I don't think the truncated Chinese character is specifically the problem, I feel like it's more likely to be JS running JSON.parse on the preference value and resulting in an error.
Jan 15 2023
I didn't reset all preferences, the only thing I did reset was that specific preference string. I believe that is what caused my bricked preferences - failed to parse a (JSON) string type from the string-typed value when starting 2017 editor. I suppose it's normally saved like "visualeditor-findAndReplace-findText": "\\"[escaped content]\\"", but the latter escaped closing quotation mark was purged by overflowing the maximum length of preference strings I think? And such leaves me with "visualeditor-findAndReplace-findText": "\\"[very very long escaped content]" which is not a proper type and can't be parsed.
Aha, found the problem. I have visualeditor-findAndReplace-findText filled with a very long string (probably accidentally copy-pasted). Setting it to a blank string fixed things... I think.
Jan 14 2023
@Func is there a way for me to completely reset my preferences for zhwiki specifically so I can get out of the bricked situation? It's been annoying having 2017 editor broken.
Jan 13 2023
I feel like what broke all of the above would be the latest 1.40.0-wmf.18 version, since before that range of deployment dates I don't feel like there are any of such issues.
Reopening per T326696#8522469, this is not a simple duplicate. @Bugreporter, T275147 is for developers to determine what to put for the empty state, and this is a bug report for interwiki and language links not loading on specific sites. I have faced the exact same issue on Chinese Wikipedia where language and interwiki links would not load under the Vector 2022 skin even on pages with linked pages. Example being while using Vector 2022 (e.g. on https://zh.wikipedia.org/wiki/Wikipedia:关于?useskin=vector-2022) shows the abovementioned empty menu incorrectly, while the old Vector skin can show such links (https://zh.wikipedia.org/wiki/Wikipedia:关于?useskin=vector).
Using Vector 2022, no links shown | Using old Vector, links correctly listed |
Hey there @Func, I noticed that my interwiki language menu has also been bricked in the same way as T326788. Is it possible that these issues could be inter-related?
Nevermind, I tried checking it while logged out and it seems like they aren't related, and it seems to happen consistently across zhwikipedia, reopened that task instead.
Jan 12 2023
@Func I understand the part that my preferences are likely bricked somewhere - I guessed this is the most likely option given that the issue is across devices for me. However I do not particularly understand how to use the abovementioned task. I've searched up mw.user.options.set in the page HTML and found one blank call mw.user.options.set(), yet the line has tokens in it and I'm better off not sharing it (line starts with (RLQ=window.RLQ||[])).
[Intervention] Images loaded lazily and replaced with placeholders. Load events are deferred. See https://go.microsoft.com/fwlink/?linkid=2048113 load.php?lang=zh-hk&modules=ext.CodeMirror%2Ccharinsert%2CeventLogging%2CnavigationTiming%2Cpopups%2CwikimediaEvents%7Cext.CodeMirror.data%2Clib%7Cext.CodeMirror.mode.mediawiki%7Cext.centralNotice.geoIP%7Cext.centralauth.ForeignApi%7Cext.centralauth.centralautologin.clearcookie%7Cext.cx.eventlogging.campaigns%7Cext.discussionTools.init%7Cext.echo.api%2Cinit%7Cext.uls.common%2Ccompactlinks%2Cinterface%2Cpreferences%2Cwebfonts%7Cjquery%2Cmoment%2Coojs%2Coojs-ui-core%2Coojs-ui-windows%2Crangefix%7Cjquery.client%2Ccookie%2CtextSelection%2Cui%7Cjquery.uls.data%7Cmediawiki.ForeignApi%2CString%2CTitle%2CUri%2Capi%2Cbase%2Ccldr%2Ccookie%2Cexperiments%2CjqueryMsg%2Clanguage%2Cstorage%2Cuser%2Cutil%2CvisibleTimeout%7Cmediawiki.ForeignApi.core%7Cmediawiki.editfont.styles%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%7Cmediawiki.page.watch.ajax%7Coojs-ui-core.icons%2Cstyles%7Coojs-ui-windows.icons%7Coojs-ui.styles.icons-editing-styling%2Cindicators%7Cskins.vector.es6%2Cjs%7Cskins.vector.icons.js&skin=vector-2022&version=1bj5z:1247
@Aklapper Added, though I don't see the point when literally every single page edit action and IP contribution page is broken.
@Aklapper Thanks for the notification, edited the request. I can't really fill in any steps to reproduce the issue as I didn't do anything specific to break it, it was working as intended until some random time where I changed nothing.
Jan 11 2023
Jun 15 2022
Apr 28 2022
@Stang I think it would be fine to configure it in the same way as Chinese Wikipedia.
May 10 2021
@matmarex
I finally found out what exactly the problem is.
Using Traditional Chinese and Simplified Chinese as display language, the fonts used are also different.
When using Traditional Chinese (incl. Trad. Chinese (Taiwan), Trad. Chinese (Hong Kong), Trad. Chinese (Macao)) as display language on Chinese wikis, the editor first loads with the Simplified Chinese font by default and then the syntax highlight overlay uses the Traditional Chinese font. Since the two fonts have different character widths, the editor doesn't actually match with the overlay. I can also reproduce this even in Fandom which also supports syntax highlighting. Please check if you can reproduce this again using Traditional Chinese as the display language.
Jan 11 2021
Thread bump and update: it seems to using the very same font for any configurations of edit tool font set in my preferences (on zhwiki), and in fact has a different character spacing causing the shift. Any idea what could fix this?
Nov 3 2020
Btw, in enwp, it does correctly use monospace fonts so that isn't a problem, but this problem exists in zhwp where it's not using monospace fonts as configured.
Oct 26 2020
So... are there any ways to solve this problem?
Oct 17 2020
It is actually not using monospace fonts as set in my preferences.
Oct 16 2020
Anyways, I suppose it should actually force the use of a (common) fixed-width monospace font instead of somehow using weird fonts that mess things up?
Oct 15 2020
Yes, I did actually experience this on multiple devices, from desktop computers to computer tablets.