Out of curiosity, what was that error and where was it fixed? (If this can be disclosed safely.)

In T371191#12172475, @Krinkle wrote:

It's not ideal design-wise, as I think a good interface wouldn't require an always-visible textual hint. But, I don't have a better idea in the interim so I've merged and deployed this.

When I saw the task title, I didn’t understand how AWB should handle them – it uses MediaWiki to parse pages, doesn’t it? Genfixes makes sense, but I think they’re worth being highlighted in the title as well.

In T434697#12214684, @Les4353 wrote:

在T434697#12213707中，@Tacsipacsi写道：

@Les4353 Thanks for claiming it! Please note that the issue has already been solved in FlaggedRevs, so the task is basically porting the fix to Codex.

Sure! Also, after upstream fixed, the downstream patch should be reverted.

So your proposal @Amitie_10g is that if someone doesn’t state their gender explicitly, we assume that they prefer male pronouns? I think that’s a bad idea. While namespace translations currently mostly assume neuter = male, a lot of message translations do make a distinction, carefully choosing a neuter translation that is as neutral as possible (e.g. thank {{GENDER:$1|him|her|them}} in English, or {{GENDER:$1|ihm|ihr|dieser Person}} danken in German). If we’d throw out these careful translations and start to call anyone whose preferred pronouns are unknown a “he”, that would be basically going back two decades. We shouldn’t do that.

@Les4353 Thanks for claiming it! Please note that the issue has already been solved in FlaggedRevs, so the task is basically porting the fix to Codex.

I could reproduce it upstream by tweaking the HTML of the the CSS-only demo, but not with the Vue version. Can this be fixed in Codex rather than downstream?

It’s not only that individual methods are not @stable to override, not even the class is @stable to extend (Stable to extend). Yet, a dozen extensions extend Article (of which two are in WMF production: GlobalUserPage and TimedMediaHandler).

It can't be checked via API request inprop=intestactions for a particular page for some reasons, response returns true even if the page is not in reviewed namespaces.

The user group autoreview does exist and has 270 members. The discussion linked above was only about the reviewer group, not about entirely removing FlaggedRevs from ukwiki, so autoreview should remain.

In T332644#12190328, @Samwilson wrote:

I didn't mean to ignore the points you've raised!

Drastic idea: what if the special page used no API requests at all, but rather created the grid in PHP? Other than the “Show more” button, there are no interactive things there that would work quicker or more conveniently with JavaScript. (And the “Show more” button can also be replaced with traditional paging.) With the API limits recently introduced and the requirements for running JS at all constantly increasing, it becomes impossible for more and more people to use a JS-only interface. The Grade C promise of MediaWiki is that even in Basic, no-JS browsers, “all page and account actions are discoverable and work,” which is violated here.

I’ve asked for the signature to be changed in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1314789/comment/c9224c62_173d3f8e/, for which I’ve yet to receive an answer. Can we pause updates until my ask is either fulfilled or declined, to avoid extra work if it gets fulfilled?

@Samwilson I’m a bit disappointed this was merged without even reacting to the points I raised two days ago. Before +2’ing, it’s always useful to also look at the attached task(s), not only at the Gerrit comments.

I see, thanks for the explanation! So actually, T322092: Make it possible to modify and create reading lists is not the same as the current task – that task asked for being able to make changes at all, which is already possible as a beta feature. On the other hand, when that task was written, there used to be no default vs custom lists distinction (the screenshots in T317935 show custom lists being available for read-only access), so it probably makes sense that you merged T322092 here.

Back to the original issue of namespace aliases,

In T332644#12072880, @simon04 wrote:

I’d also call this a bug (though a borderline one, which is not far from a feature request), but bugs also have their own form, which is also linked from the top of the task creation page, so using the generic form wasn’t appropriate in that case either.

Thanks for creating the task! There are some places where I think it’s straightforward what force means (e.g. BasePage.get(force=True)), but refresh would be understandable in those cases as well, so it’s probably better to replace everything for the sake of consistency.

Wait, why is this validation on save? There are already a few checks on marking for translation, couldn’t it be moved there? The extra whitespace doesn’t cause any issues until the page is marked for translation, but it does cause frustration to average users who know little to nothing about the translation syntax and just want to get their edit saved. If the error was flagged when the page gets marked for translation, it would be the job of the translation admins (who are expected to be familiar with the translation syntax) to fix any issues – both new and pre-existing.

For someone who has used reading lists on mobile but doesn’t know the inner working of the extension, can you explain (with a few sentences or a link) what “custom” lists mean? That is, what are non-custom lists?

Thanks @HFan-WMF for finding the right task and merging it into that!

In T433503#12167793, @thiemowmde wrote:

In core, there are 85 occurrences.

I might do something wrong. But when I use the regex default:\s*break; I can only find like 7 outliers in core. All in the https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/libs/Leximorph/Handler/Overrides/Grammar/ directory, all from the same patch https://gerrit.wikimedia.org/r/1176757.

In T430257#12171200, @abi_ wrote:

Verify that markup structure matches what's displayed on https://translatetagger.toolforge.org/

Hi @Axolitl, and welcome to Phabricator! There are multiple ways to get link autocomplete in DiscussionTools, which use different pieces of software. To find out which one you’re complaining about, can you describe a bit more precisely where you experience the issue?

For clarity: this request is about the source mode, right? In visual mode, a such button would make no sense: what you type there automatically gets nowiki’d.

Yes, because the approach of that patch didn’t work out. This doesn’t mean the bug shouldn’t or won’t be fixed, but the patch author didn’t have the time/motivation/etc. to fix this at the time. The bug being fixed is as likely as it was if there has been no patch yet – not impossible, but apparently not a priority either.

Thanks for checking back on this!

I see, thanks for having implemented my wish before I said it! ☺

In T432071#12148420, @matmarex wrote:

How do you think it should look?

Thanks for the confirmation! I updated the description to make this hopefully clearer.

MathJax is used as default rendering engine for math environment

wikimedia-globalblocking-blockedtext-ip-range and wikimedia-globalblocking-blockedtext-proxy are also the same as their non-overridden GlobalBlocking counterparts, could they be removed? (I know this is a three-year-old task, but I stumbled upon it now.)

In T301088#12110777, @nah_omy wrote:

I understand the difference between the vector versions.

Thanks for looking into the history and choosing a license!

In T301088#12109623, @nah_omy wrote:

I'm sorry, I didn't express myself clearly. What I mean is that I reviewed the code and found the problem in vector-2022

Thanks for attaching the image! The screenshot was made on Wikipedia, but Wikidata-Page-Banner is only installed on Wikivoyage – this is why I linked a Wikivoyage page in the bug report. (When picking up tasks on Phabricator, you should always look at the project tags, they describe what broad component the task is related to even when the title and description are silent about this.) Did you try it on the linked page?

In T389944#12104953, @Nikerabbit wrote:

There are some classes still in […] messagegroups/ […].

@nah_omy, I’m glad you want to pick up this task.

@Shashwatojha369, thanks for your willingness to help, but I think this task should be solved by the original authors of the code – they are the ones who are legally allowed to license their work. As far as I see, most early commits are from @hashar and @Krinkle. (On the other hand, I’m looking forward to you solving T431661: Add dark mode to integration.wikimedia.org; that task has no legal problems.)

Depending on permissions. Both userspace and community saving require separate permissions (collectionsaveasuserpage and collectionsaveascommunitypage respectively), so that wiki administrators can allow user a given user group to do both, either or neither. Also, both saving options require the user to be registered (“registered” includes temporary users), which I think makes little sense – if a wiki administrator wants to require registration for saving, they can give the permissions to the user group, but if they want to allow IPs as well, why should they be stopped?

In T430613#12097952, @Nikerabbit wrote:

There was a couple 503 errors from gerrit last night, but that seems unrelated.

I don’t see the ability to add chapters on the requirements list. Do reading lists already support that?

The goal of the present task is to be able to create a chart with no data table – the life expectancy chart does use a data table, WDI/SP.DYN.LE00.IN data.tab, so it’s indeed not what the task is about.

using a separate tag would be more useful

Thanks for updating the screenshots!

I’m not sure if the notifications should generally be disabled.

If it’s a duplicate, please close it as a duplicate (rather than as declined), merging it into the other task – this connects the two tasks and automatically copies subscribets. If it’s not a duplicate, please don’t say so, and keep the task open until the work is finished.

I believe this was broken by the work on T429624: Link to edit TemplateData is broken with Parsoid Read Views and should have been fixed by @cscott's last patch (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1306996) about 15 hours ago. I can confirm that purging https://nl.wikipedia.org/wiki/Gebruiker:LLTSU/Kladblok fixes the button on that particular page.

A purge fixed it. I’m not sure if it’s worth debugging.

In T395347#12056373, @Krinkle wrote:

In T395347#12038096, @Tacsipacsi wrote:

Your listings don’t include iPads and iPod Touch devices, was this intentional?

[…]

Yes, in so far that my list wasn't intended to be exhaustive or complete. The idea is that iPhone represents the majority of the mobile device market for Apple and, and iMac/MacBook represent the desktop market (with I chose iMac for representing a more conservative audience where devices are supported/used longer than laptops).

Unless iPod Touch or iPad support length from Apple look significantly different, or have outsized importance for MW/WMF, it didn't seem worth including as it wouldn't change our timeline or decision.

Is it fixed even if the revert doesn’t restore a previous version of the translation page? Consider the following scenario:

Option 4: promoting subscribe (with icon)Subscribe + watch

I’ve run into another problem:

Was this done? There are no linked Gerrit changes, and neither do I remember anything having happened in this area. If it wasn’t done, the task should be closed as declined, not as resolved.

@cscott, what does T424409: Remove old Parsoid language converter implementation mean for this task? Does it have to be fixed in the new implementation? Is it already fixed in the new implementation?

In T209394#12038874, @cscott wrote:

Extensions and skins have their own composer.json

Your listings don’t include iPads and iPod Touch devices, was this intentional?

In T209394#12037436, @cscott wrote:

When run in mediawiki-core, a set of MediaWiki\* namespaces would be friends, but a call to an @internal method of Wikimedia\Parsoid would be flagged.

rETDA includes/Hooks.php:186 (at d96be0435c17fad10e66716001fa8cfe7d1ec65f) reads the page title as PPFrame::getTitle(), so that’s what’s wrong. I didn’t look up how that works in core, I hope you know that better than me anyways.

Why does the deeper fix need a hook – why does that code run at all on Commons file pages? Since Commons file pages work pretty differently, couldn’t the whole FullEntityParserOutputGenerator be skipped on them?

In T424442#12010695, @MusikAnimal wrote:

CodeMirror users generally want it everywhere there is editable wikitext or code.

In T429085#12016594, @Raymond wrote:

"ignored" and "optional" are added to the translatewiki.net configuration file manually based on the message content. The message documentation could be a hint but is never the main criterion.

Thanks for the fix @matmarex!

Good point, I forgot this. I was wondering why I see the brackets on https://translatewiki.net/wiki/Support even though I have visual enhancements enabled… So it affects even more high-traffic pages (village pumps, noticeboards etc. on all wikis). I still don’t think it’s UBN (it’s just a tiny annoyance), but I still hope it can be fixed tomorrow.

I think it only affects users and wikis without visual enhancements – the latter means enwiki. So considering default user preferences, it affects only one wiki, but a pretty large one.

What license does the dashboard have, and where is its source code? The Phabricator project description lists only https://github.com/thelounge/thelounge/, but that’s the main service, not the dashboard. Per the Cloud Services Terms of Use, all software deployed to Cloud Services, including Cloud VPS, must be open-source. The best would be if the dashboard itself would link to its source code, but listing the source code in the Phabricator project can also work (or even both – the footer link is more convenient, but the Phabricator one is accessible even if the dashboard is down and someone wants to debug why it’s down).

In T428744#12005947, @stjn wrote:

Additionally, it should be noted that you cannot use https://hu.wikipedia.org/wiki/Wikipédia:Törlésre_javasolt_lapok?cdenable=0&dtenable=1&uselang=en to reply even if you are allowed to edit the page:

This change would also be able to reduce API requests on those pages since even hovering over those links is making 3 API requests (probably to improve the loading time of the tool).

It’s a good idea, I’m also annoyed by this at times – when I see a suggestion, I’m not sure where it comes from and whether I should keep consistency with it (e.g. if the same word is translated in both MediaWiki core and in FreeCol, the translations don’t necessarily need to match, but if both translations are in MediaWiki core, they probably do need to match). For the wording of the button, why not just say “used 1 time”, for complete consistency with the multiple-use case?

The text (“This user has advanced knowledge of English”) should be exempted by T39617: Do not convert text marked as being in another language with a lang attribute once someone implements that, since that has proper language markup. (As you requested, the Crimean Tatar text wouldn’t be exempted, since the proper language markup tells that it’s in Crimean Tatar.) The language code (en-3) has no lang attribute currently, but Babel could mark it up with lang="zxx" (non-linguistic content), and then T39617 would fix that one as well.

With ?uselang=hu, I do see Arabic on the Arabic page. Maybe the canonical English parse was done before the row of the page was inserted in the database?

With the implementation being in Rust, it needs to be added as a microservice (if the setup supports that – WMF production certainly does, but I’m not sure about translatewiki.net, let alone third-party wikis), it cannot be added to the extension directly. Is there any reason you wrote this in Rust rather than in PHP?

Some background: The tracking category was added for T324139: When the lede section has comments, they should not be pulled into the "Learn more" popup. It’s disabled by default, but can be enabled by creating MediaWiki:Discussiontools-comments-before-first-heading-category. The tracking category is added in rEDTO includes/CommentFormatter.php:445 (at 8a18c123d37a5bf8cabce1f35d913e6f72ea8247), which is called from two hook handlers living in rEDTO includes/Hooks/ParserHooks.php (at 8a18c123d37a5bf8cabce1f35d913e6f72ea8247): one for ParserOutputPostCacheTransform and one for ParserAfterTidy.

Side note: you may want to link to the form I used (https://phabricator.wikimedia.org/maniphest/task/edit/form/43/) rather than the generic https://phabricator.wikimedia.org/maniphest/task/edit/form/1/, so that people are guided how to report a bug.

Same for the regex \b(tright|tleft)\b (https://global-search.toolforge.org/?q=%5Cb%28tright%7Ctleft%29%5Cb&regex=1&namespaces=&title=), I guess it’s the same underlying bug?

(Closed by new Phab account, who has an indefblock on-wiki. The bug may have been fixed in the meantime, but I’m pretty sure @Nawaf2296 didn’t test it before closing.)

Actually, the clock used to be in the personal menu. I argued multiple times on https://www.mediawiki.org/wiki/MediaWiki_talk:Gadget-UTCLiveClock.js that it should remain there, but others had other opinions. If there’s still no willing to revert this decision, it should also be possible to add the clock at both places and hide unnecessary ones (based on screen size) using CSS. (Even earlier, the watchlist button also used to be in the menu, but I guess people were dissatisfied with it being one more click away, so Vector 2022, which started as a cleaner skin than Vector 2010, has slowly become IMO just as bloated as its predecessor.)

A very hackish solution (but the whole code is hackish, so it wouldn’t make it that much worse): what if the config code directly accessed $_REQUEST['action']? That would mean no need for changes in VE or DT.

Yes, this is noted by the description (it refers to this issue as “non-prose data”).

As I wrote, I think moving them the other way round would be a better idea. In any case, ukwiki was solved in this task, ruwikinews was recently solved via T423578: Remove custom user groups from Wikinews (in core-Permissions.php), are there any other wikis with permissions at both places?

@Legoktm There’s an open patch by you. If you unassigned the task, maybe you want to abandon it. Or do you hope that it’s going to be merged one day without you working on it? (My interpretation is that it’s waiting for you, but you may think otherwise.)

In T426732#11947138, @1F616EMO wrote:

The acceptance criteria to (2) is that one can use native wikitext (ideally wikilinks [[...]]) to link to any comments, including those that contains illegal title characters as of now. This can be solved by […] introducing a new magic word (I imagine something like {{#comment:c-Example-YYYYMMDDHHMMSS}}, similar to how we invented {{#interwikilink}} for moswiki) for linking to comments.

Which Template Talk page? The Google doc is still non-public, and there’s no other list referenced in this task.

In T426539#11929091, @SomeRandomDeveloper wrote:

Thanks for notifying me, I think this is caused by c58febaa602036d64f05ae1f831fe08caf321d97 (which is not related to the task you mentioned, but also a patch I made). When ApiEditPage is executed, it only updates $wgRequest and not the request in RequestContext::getMain(). AFAICT this only affects VisualEditor because it uses a DerivativeRequest to call action=edit internally when an edit is submitted.