In T326696#8541807, @Umherirrender wrote:

The next time the broken option is changed, it would fix itself.

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.

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.

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.

@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.

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.

@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||[])).

@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.

@Stang I think it would be fine to configure it in the same way as Chinese Wikipedia.

@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.

@matmarex

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?

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.

So... are there any ways to solve this problem?

It is actually not using monospace fonts as set in my preferences.

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?

Yes, I did actually experience this on multiple devices, from desktop computers to computer tablets.