User Details
- User Since
- Oct 17 2014, 6:53 PM (491 w, 3 d)
- Availability
- Available
- IRC Nick
- MatmaRex
- LDAP User
- Bartosz Dziewoński
- MediaWiki User
- Matma Rex [ Global Accounts ]
Today
Thanks for the note, the setup script worked the last time I used it, but I can help debug if it doesn't work any more :)
Fri, Mar 15
If you want to work on this, I think it needs to start with inventorying the existing gadgets to inform the design of the new API. Otherwise we risk spending time on something that doesn't actually serve the practical use cases. Until that happens, we need to continue supporting the de facto API of the .mw-editsection CSS class and associated markup.
Thu, Mar 14
(I'll look into this in a week or two after I'm back home, but feel free to take it over from me if you're feeling bored)
Oops, sorry about that. Thanks for fixing it for me.
Wed, Mar 13
I think this is an old problem, previously reported in T177617. Your investigation has a lot more detail though, so maybe we should merge that task into this one.
Tue, Mar 12
Per previous comment.
(I won't have the time today to backport this, I hope someone else can do it.)
I spent a few minutes re-reading the code, and I think page_len is always set, but the titleInfo array we're building in that code is multi-dimensional, and we got confused about which level we're on.
Mon, Mar 11
Thanks!
There's no built-in mechanism in ResourceLoader, but it's fairly easy to implement it for your own module, for example:
- https://gerrit.wikimedia.org/g/mediawiki/extensions/DiscussionTools/+/c5044b08223d9676578ff96067aae856dda7fa6d/extension.json#269
- https://gerrit.wikimedia.org/g/mediawiki/extensions/DiscussionTools/+/c5044b08223d9676578ff96067aae856dda7fa6d/includes/ResourceLoaderData.php#120
(This would work when defining the QUnitTestModule as well.)
This has been fixed somewhere in the recent ParserOutput refactoring, I don't feel like figuring out which patch exactly did it.
Presumably fixed.
Yes, it will. (Although you'll need to update it again when the other changes in this task land – see https://www.mediawiki.org/wiki/Heading_HTML_changes.)
Sun, Mar 10
Wrapping the collapsed fragment in <div class="mw-notalk">...</div> or in <blockquote>...</blockquote> (as documented at https://www.mediawiki.org/wiki/Help:DiscussionTools/Magic_words_and_markup) would also make the subscribe button and discussion metadata work as intended.
I'm not sure if this would be a good idea, there are some monospace fonts that include ligatures for some sequences like -> and != (see e.g. https://www.hanselman.com/blog/monospaced-programming-fonts-with-ligatures) and we probably shouldn't disable these if the user chose to use such a font.
Sat, Mar 9
Well, the good news is that it's a problem in the installer, so having it set up wouldn't really help ;) I would mostly rely on CI to test it for me, testing the installation process is annoying enough already.
Fri, Mar 8
@stjn I didn't know about that. Well, again, it's my bad.
Sorry, I was busy recently and haven't looked at this task.
Thu, Mar 7
More examples: T89947#9538996, T352308#9609776 (I swear I'm not going looking for them, these are just from tasks in my inbox, so this seems like a common problem)
Wed, Mar 6
The interface flag should be set when parsing wiki interface, and unset when parsing wiki content. It's checked only to enable and disable some parser features in the interface and content: https://codesearch.wmcloud.org/search/?q=getInterfaceMessage (the reasons behind of them are more obvious than others… don't ask me why these features in particular).
I don't really have time to dive into this, but if we're okay with the predicted increase in the number of temporary accounts, then this seems fine to me. In fact logging AbuseFilter hits this way seems like an improvement, and it probably makes a lot of things easier to implement (and design, and communicate to users).
The fix will be deployed to Wikimedia wikis next week, between Tuesday and Thursday, per the usual schedule.
Yes. The fix will be deployed to Wikimedia wikis next week, between Tuesday and Thursday, per the usual schedule.
Resolved in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ORES/+/1003397, I don't know why the bot didn't tag it.
It looks like we already treat this field as a standard binary(14) timestamp in the code in some places, e.g.:
Tue, Mar 5
Deployed to all wikis, looks fixed.
Sure.
I'm sorry everyone, I wanted to backport this fix yesterday, but the deployment window has been cancelled due to problems with the platform (T359155), and the same thing happened when I tried again this afternoon. I'll try again when the problems are resolved.
scrollbar-gutter is supposed to be one of the things browser makers want to work in 2024: https://web.dev/blog/interop-2024 so I would say there's a chance.
Yeah, I agree with that. Score isn't recognized in signatures because it outputs a <div> tag. It doesn't work for the same reasons that <math display="block"> and <pre> don't work.
Mon, Mar 4
I'm glad you reviewed that code, since these patches were all clear improvements, but I'm not a fan of the ones using factorConds(). I wasn't even aware that this method exists before, and although it's neat now that I know about it, it doesn't seem that obvious what it does. I think it's important that the query building code clearly says or/and, anyOf/allOf, or something like that, instead of having all of the operators be implied.
Reported upstream: https://github.com/mck89/peast/issues/68
Reported upstream: https://github.com/mck89/peast/issues/68
The plwiki script has been reworked to avoid ResourceLoader minification, so this isn't urgent at this point. See:
(It's live on the beta cluster now, if you want to double-check: https://en.wikipedia.beta.wmflabs.org/wiki/Talk:Main_Page)
I understand that this is not the solution you're asking for, but just in case it helps, let me note that there's an Atom feed (like RSS) available for your watchlist – you can access it by clicking the "Atom" link in the sidebar (it will generate a URL with a secret token that allows accessing your watchlist without logging in).
May be the same as T358946, there is a similar regexp in the source code here: /\n={3,}/. I'm confused why it would only fail intermittently though…
Sun, Mar 3
This doesn't seem specific to DiscussionTools. I see several problems on mobile when using Parsoid read views.
Sat, Mar 2
Minimal test case: Peast\Peast::ES2016( '/=\n/' )->parse();
I applied a temporary workaround in the gadget: https://pl.wikipedia.org/w/index.php?title=MediaWiki:Gadget-sk.js&diff=prev&oldid=73036090
I reproduced locally, it's caused by the mck89/peast upgrade from T357477 (which fixed a different bug like this). That was already deployed a week ago, but I guess we cache these for a while.
I guess that also works, but I really think this is a problem on the Phabricator side. Our repositories are big enough that 7-hexdigit hashes are too short to be unambiguous. Git itself uses adaptive length depending on the repo size, and I'm seeing 11-hexdigit short hashes in my clone of mediawiki/core (and if it knew about all the other repos, they'd probably be longer).
Fri, Mar 1
Thanks!
@AlexisJazz FYI too, looks like Factotum does some stuff to the links/buttons.
@Jack_who_built_the_house FYI, in case Convenient Discussions depends on the current markup. You can try the new one in the demo above.
You can verify that by searching for the error messages generated by Firefox, which include more details.
Noted in https://meta.wikimedia.org/wiki/Tech/News/2024/10. Current draft:
The HTML markup of headings and section edit links will be changed later this year to improve accessibility. See Heading HTML changes for details. The new markup will be the same as in the new Parsoid wikitext parser. You can test your gadget or stylesheet with the new markup if you add ?useparsoid=1 to your URL (more info) or turn on Parsoid read views in your user options (more info).
The link is added by a gadget (there are lots of gadgets that add an edit link to the top section, and they're all slightly different). I can have a look at why it's not adding it in the Parsoid version.
Thu, Feb 29
This happens because DiscussionTools's CommentFormatter, and MediaWiki core's HandleSectionLinks, expect different HTML serialization.
Looks like the bug only affects pages with DiscussionTools (not main namespace). It's actually the > by itself which triggers the problem. It's probably somehow caused by rMW834ff25dc1ab: Move section heading formatting to post-cache transform (take 2).