In T267839#11421762, @Hex wrote:

Updating signatures is something I do from time to time but there are definitely some folk who frown on the practice. I'm pretty sure getting a bot to change your old signatures en masse would draw a lot of heat?

Especially in case of the “Latest comment” headings, but partly also in case of the pings: if someone wants to have their new user name reflected, they should update existing signatures (e.g. via a bot). I’d find it quite confusing if DiscussionTools said the latest comment is by User:New_name, but (looking at the signatures) only User:Old_name has ever commented in the topic/on the page.

This caused accessibility check errors: form elements must be labeled. The check doesn’t say “form elements must be labeled unless the meaning is obvious”, it says they must be labeled, period. I’m honestly surprised OOUI allows skipping the label without even a warning.

The message currently looks like this:

Thanks for the response! So it’s ready to be worked on, even if that work is unlikely to happen in the near future (at least by staff – maybe part of the analysis can be started a knowledgeable volunteer or a staff member in their volunteer capacity). “Stalled” means that the task is not ready to be worked on, due to waiting either for input from a specific person or group (“someone needs to analyze this” is not a specific person or group), or for a subtask to be resolved (the current task has no subtasks at all). Feel free to move to a “Low-prio/Future” column on the workboards, but the task is, by definition, open, not stalled.

Patch merged, lint error list mentioned in description empty, page chosen at random https://en.wikiversity.org/wiki/Electric_Circuit_Analysis/Circuit_Analysis_Quiz_1 looks good, I think we can call this done. Sorry for not following up on the merge earlier.

The MR is actually ready, simply the description did not use to match the regex used by @CodeReviewBot. I’ve updated the MR description.

Actually, calling the API from the middle of a parse is a pretty bad idea. You could query the list of subpages, but what would happen if later a subpage was created or deleted? Nothing, because there would be no indication of this connection, so MediaWiki would have no way to know it needs to invalidate the parser cache. A feature directly added to Scribunto could add a row to the appropriate database table to indicate this connection.

Actually, maybe a warning should be added even for translation admins using the legacy interface. I’ve been importing zh-hans and zh-hant translations on Wikimedia wikis upon converting legacy templates to Translate for a long time before realizing that they cannot be edited by Chinese translators. (But this may be for another task.)

https://en.wikipedia.org/wiki/Special:MovePage/nonexistent1 shows no help link at all, Translate should be consistent with that. (Or the help link should also appear on enwiki – I think that would make more sense, but it’s probably a different task.)

It definitely looks like the same mistake, although it may be that the same mistake was made twice, as opposed to the same buggy line being hit both times (which is what I’d call “same root cause”).

I’d also welcome this, but

Why is this dependent on the revtag table? If a translation is prefixed with !!FUZZY!!, the export script could simply remove that prefix without consulting the revtag table. Or would that cause problems?

Similar bug (but the fix will probably be completely different): T410746: Broken translatable pages can be moved without related pages.

@hashar What is this stalled on? (I understand T147864#10541736 that it’s not a priority right now, but “stalled” is stronger than “not a priority”. I’d also appreciate true SSO.)

In T232454#6733210, @Krinkle wrote:

With the recent work on DiscussionTools, the server-side part of this in terms of serialising and inserting new replies is also pretty much done.

What happens if you write

In T409655#11359166, @Nikerabbit wrote:

It should round trip fine, but please let us know if it doesn't. Maybe the code that supports that is broken.

The convention of ParamValidator for such cases (e.g. rMW includes/libs/ParamValidator/TypeDef/FloatDef.php) is 1/2: that can be used with {{PLURAL:}}, which is core, not only with ParserFunctions’ {{#if:}}.

Can %s be used with GENDER in this context?

And looking at the code, I realized simply adding explicit |other= fixes the issue, maybe that could be mentioned in the error messages. (This may be something for T409665, though.)

In T409655#11358674, @Dbrant wrote:

It looks like this can be worked-around by making sure the raw HTML is outside the PLURAL template, i.e. wrap the PLURAL template only around the minimum required text to be pluralized:
https://translatewiki.net/wiki/Wikimedia:Wikipedia-android-strings-year_in_review_slide_most_read_english_articles_body/de

I see your point, but the problem with this approach is that it potentially blocks unrelated development, like in my case. I find the approach of Dependabot much better: it constantly updates dependencies, but in separate PRs (changes in Gerrit speak), so if a new dependency version breaks the code, CI fails only on that change, and not everywhere. Also, the CI failure is less mysterious, since it’s no longer tied to the timing, but to code changes.

Thanks for fixing it! Why aren’t dependencies fixed at least at major versions by default? At least for dependencies that follow semver, major version upgrades are always risky and shouldn’t happen implicitly.

• The full-screen view should contain an explicit "Close" button.

Note that this is not a new problem, I just took the time to report it now.

In T248277#11354648, @Vladis13 wrote:

I doubt project-wide settings in JSON format are semantically suitable as templates.

Why are these pages in the MediaWiki namespace? You could put them in the template namespace and use Special:ChangeContentModel to make them JSON, and you would have no problems with FlaggedRevs.

I fixed it (without knowing of this task), and nobody has complained in the past five years.

In T398280#11339649, @Nikerabbit wrote:

I added some from top of my head. Feel free to improve or suggest improvements.

Deploy

10 Nov

Patch/config needed

In T408995#11333598, @Zache wrote:

I think that available levels which can be used in API call is what we want, not the raw config value.

In T408726#11325986, @Zache wrote:

Other data which would be useful

• protection levels ( ie. wgFlaggedRevsRestrictionLevels values ) which is need for API:stabilize to set which user groups can automatically review revision

In T272146#11322364, @Trizek-WMF wrote:

T290778 looks like a parent task, as it covers all experiences, while this one is about a specific interface (mentorship module at the Growth Homepage).

Thanks! (Attaching is something else, but changing the visibility to public also does the job.)

In T400058#11299588, @Amire80 wrote:

In T400058#11223749, @Tacsipacsi wrote:

I’m pretty sure it’s not a good idea. As I wrote in T167762#11223704, context helps a lot to create quality translations. (As a developer, I personally don’t care much: I just grep for the message keys, which finds those wherever they are. Although other developers may work differently.)

I don't think that it will ruin the context. Messages that appear in the same screen should appear in the same group, too. If currently some messages from a given screen appear in "Most important", and some don't, it's probably a mistake in the first place.

I cannot actually do it, but what I’ve had in mind is

No, it’s not a valid bug. What currently happens is in line with the principles of the parser, what you propose isn’t. I’m tired of repeating the same thing over and over again just because you repeat the same thing over and over again; unless you come up with new arguments, I won’t respond to you anymore on this task.

So the categories can be added, they just link to wrong places. So external reusers (SPARQL, dumps, Wikimedia wikis etc.) are unaffected. I updated the task title accordingly.

With the XML fixed (T408778#11327039), I don’t think this is UBN anymore.

In T408778#11327094, @Dbrant wrote:

Yeah, the compiler wouldn't like that. If it's a plurals in the default localization, it must be plurals everywhere.

In T408778#11326710, @abi_ wrote:

I was looking at updating the code to support parsing this and reading the Android developer documentation I don't think its valid to have plurals without items.

In https://github.com/wikimedia/apps-android-wikipedia/commit/d8cfed1a9fdfb414c64805d6660d8adb7a519257#r169251039, @Nikerabbit wrote:

Translatewiki.net parser does not handle plurals without item elements and this has broken translation updates.

In T57081#11324752, @Zache wrote:

The ticket T57081 is place where you can comment about Pywikibot part.

6. _apisite.flagconfig()
   • Shows information about review flag configuration.
   • API: https://www.mediawiki.org/wiki/Extension:FlaggedRevs#action=flagconfig

This task is about a very specific part of the development. The main development task seems to be T118696: Allow to defer 'suspicious' edits for review on any page in a reviewable namespace ("Deferred changes"), if you want to question the whole project, please do so there; it’s out of scope here.

If T408566: Mentees aren't subscribed to the message they send to their Mentor using the Mentorship module is considered a duplicate of this, then it’s solved by T290778: [Config change] Enable automatic topic subscriptions in all editing interfaces, isn’t it? (“Pinging” newcomers could mean several solutions, but “subscription” can be understood in only one way, and that’s implemented by T290778.)

That page says The implementation is based on the flagged revisions extension, and most changes linked from https://en.wikipedia.org/wiki/Wikipedia:Deferred_changes/Implementation#Tasks are for the FlaggedRevs repo. So I think FlaggedRevs is indeed the correct tag. (If there are enough Deferred Changes-related tasks, maybe a workboard column or subproject could be created, but even that would belong to FlaggedRevs.)

Given the Temporary accounts project, which means soon no IP edits will be deferred on WMF wikis (as there will be no IP edits), is this task worth pursuing? It could be of benefit for third-party wikis who don’t opt into temporary accounts, but I’m not sure if that makes it worth the work.

The parser cache is there to minimize the amount of post-cache transforming, wouldn’t this approach be counterproductive? Unlike red links, the self link state cannot change due to external changes, so we wouldn’t have to invalidate cache entries just because of this. And I think “breaking parser cache” would in this case simply mean that pages appear inconsistently until the old cache entries expire; if this temporary inconsistency is acceptable (I think so), no backward- or forward-compat code is needed.

In T334372#11310608, @SD0001 wrote:

Lua can be used anywhere wiki markup can be used

In T342726#11309572, @Samwilson wrote:

(Thanks for reminding me!)

In T396889#11304240, @Amire80 wrote:

qqq is for translators and for MediaWiki developers, and it's not necessarily the best thing for system administrators anyway.

@Esanders please restore the edit history of my huwiki talk page (merge https://hu.wikipedia.org/wiki/Szerkeszt%C5%91vita:Tacsipacsi/LQT_Archive/LQT_Archive_1 into it). I used to use LQT for a short time over a decade ago, but since then I’ve been using plain wikitext (and DiscussionTools from day zero), so I’d like to see the edit history of the past decade where the edits were made: at Szerkesztővita:Tacsipacsi.

In T402004#11308467, @Novem_Linguae wrote:

Also, there is now an additional Logstash entry from plwiki: RevisionReviewForm.php:490. Flagged revision with ID 77883529 exists with unexpected fr_page_id, error: duplicate review

https://pl.wikipedia.org/w/index.php?oldid=77883529

Neither could I reproduce it, but I got close to it. What I did:

I realized that there’s something common in the three test2wiki pages and the huwiki page: they weren’t just deleted and restored, but something more complicated happened: the test2wiki pages were deleted, recreated and then restored (inserting the once-deleted revisions at the end of the revision history), while the huwiki page was split (if I understand the log messages correctly, the logo now visible at Fájl:Magyar Cserkészszövetség logo 2.svg was once uploaded over Fájl:Magyar Cserkészszövetség logo.svg, and then subsequently split out). I guess this is why MediaWiki assigns a new page ID, and FlaggedRevs gets confused by this.

In T402004#11304293, @Novem_Linguae wrote:

Oh, sorry. Try https://fi.wikipedia.org/w/index.php?oldid=23590538

In T396286#11288470, @jhsoby wrote:

It does for technical purposes, but not necessarily for language proposal policy purposes. We (langcom) do have some leeway to approve projects without their own ISO 639 code, but with a valid variant code, but in practice the threshold for doing so is very high.

From a Phabricator viewpoint, there was no problem, so this task is invalid, not resolved.

The message in question is https://translatewiki.net/w/i.php?title=Special:Translate&group=wmcz-tracker-django&language=ar&showMessage=tracker-e540cd-index&optional=1 (https://translatewiki.net/wiki/Wikimedia:Tracker-e540cd-index/ar), and this is not a stack trace, but a list of Gettext “references”, i.e. locations where this message appears.

In T68762#704259, @kaldari wrote:

Since it isn't mentioned anywhere else... The immediate impetus for this bug is so that we can set the 'Mobile-frontend-terms-url' message to '//m.wikimediafoundation.org/wiki/Special:MyLanguage/Terms_of_Use' via the WikimediaMessages extension, so that people clicking the 'Terms of Use' and 'Privacy Policy' links at the bottom of the page will get sent to the pages in their own language as they become available.

+1. As a translator to Hungarian, I sometimes replace Special:MyLanguage links with links pointing to /hu pages (when they exist at the time of the translation) to avoid this problem, as I believe this provides a better UX – but an “official” solution, supporting the fallback chain and all languages, would undoubtedly be even better.

Nothing has changed in this regard since rETRAd044713a2a59. rMW062cfffeb2d132ead4d7d786c96dce5e7a0bc557 (committed two years before rETRAd044713a2a59) promised the red-link part will be moved to core in a follow-up commit, but that hasn’t happened in the past 11 years.

"what links here" broken

In T342726#11243338, @Samwilson wrote:

• Delete https://www.mediawiki.org/wiki/Manual:$wgEnableEditRecovery

The point is that <syntaxhighlight> is intentionally not “nowiki-like” with respect to <translate> tags, because otherwise it’d be impossible to make parts of a code block (e.g. comments, or the text “Some template” in https://www.mediawiki.org/wiki/Help:Extension:Translate/Page_translation_administration#Translatable_page) translatable.

That’s a special page, not exactly helpful. ☹ Any chance we can find the actual article? For example using the revision ID included in the message (at least the message in the task description contains it)?

In T375231#11303630, @Jdlrobson-WMF wrote:

@Tacsipacsi using the dialog with teleport target would also work here

English Wikipedia does this: https://en.wikipedia.org/wiki/MediaWiki_talk:Accesskey-pt-watchlist (Template:Interface explanation). I vaguely recall having seen this elsewhere as well, but I’m not sure where (if at all).

I see. What about just highlighting the fact that now any editor works, without naming any one of them?

I don’t see documentation on the CSS-only version of Popover. This popup essential information, so it should be available without JavaScript. (Currently it isn’t, but we shouldn’t lock ourselves in a component with which it’s impossible to fix this accessibility issue.)

Do we really call action=edit the “source editor”? I find it slightly confusing, as DiscussionTools also has its source mode. Isn’t there a more specific term? (As far as I understand, this change affects other ways as well, such as action API, VisualEditor if enabled in the namespace, etc., but those are probably not worth being mentioned. Except maybe the mobile apps – or do they already auto-subscribe?)

What is the fiwiki page? (I don’t have access to Logstash.) The huwiki page has been deleted and undeleted between @Boro's recent edit and the previous one, so I think it suffered from T162778: If reviewed page was deleted and then undeleted, page is marked both as reviewed and unreviewed; maybe it’s the same on fiwiki?

Did someone check this from an accessibility perspective? A missing heading can make the accessibility tree harder to navigate; I fear a cosmetic improvement will make the content less accessible here.

CodeMirror would be especially useful in DiscussionTools, since templates can't be used in the visual mode, forcing users to write complicated syntax without the assistance of syntax highlighting.

In T407880#11295298, @Spartan.arbinger wrote:

not really this is to get the title of the current section heading

In T292969#11292200, @Boro wrote:

Note that if this case is not handled by the implemented solution, it's still relatively hard to fix by replacing the sub-class letters with the actual names. Doing so would end up creating a parameter with 30+ suggested values without any way to add separating items (similar to what the Upload/Licensing field has). Merging the two parameters has the same issue of excessive number of items.

No, it should not be “fixed”; I explained above why. (And, by the way, it’s not even a bug: the way it works now is by design. The change you ask for would be a new feature, not a bug fix.)

Then it should be declined. Wikitext parsing traditionally works by trying to make sense out of the input as much as possible. A red link (which shows the error message when navigated to) may fit in this, an error message definitely doesn’t. Error messages are only used when there’s absolutely no way the input can be interpreted, like infinite template recursion, Lua errors, or non-numeric input to {{#expr:}}.

Oh, I see it’s not a new idea of yours that these links should be used in wikitext. As I wrote in T63547#11288449, I don’t think they should, and there is a solution that already works as expected in wikitext, without any need for software changes.

In T63547#11288919, @Bugreporter2 wrote:

[[Special:TalkPage/]] was introduced based on a specific use case.