While the French word for the French language is "français", that word is still capitalized in title case. So we would only want to change to a lowercase "français" if the idea were to shift away from title-casing in general. Personally I'd actually prefer the look of things with all sentence-case endonyms, but that's a bigger discussion, and at least last time this was discussed (see description) there was consensus for the title-case approach.

Just commenting to say I agree this is not the correct behavior. There's a semantic question here: Is this a list of endonyms rendered in their title-case form, or is this a list of loanwords rendered in the interface language' title-case form? Most of the way the language list works suggests the former. For instance, otherwise we would not be using non-Latin-script names in English, in which most style guides would call for using a romanization. Further, if the goal were to just follow the norms of the interface language, it would make more sense to use exonyms entirely. To me it seems like the goal is that each entry should represent how that language's name would appear in title-case in that language. In the case of Toki Pona, that is "toki pona".

I think we were able to? @Tbodt would know.

@A_smart_kitten, I self-reverted after remembering T404507#11181616

This technically wasn't stalled, but there wasn't much reason to get around to it till now, so, noting that T404457 has now been resolved and tokwiki exists.

No, it wouldn't break anything, and actually because of how Toki Pona grammar works, even an article like "Word: Live at Carnegie Hall" would have its title begin with a common noun before you get to the start of the work's title. If there's a benefit in having an English-language namespace alias, then I have no objection.

@taavi: Sorry, to be clear, there's no need for namespace aliases of Word and Word talk. Those were just translations I gave to explain what we're using the namespaces for.

@A_smart_kitten Yeah, that'll show you how long this has been in the works! Those configs were still in use when the proposal began.

I think visible to everyone, but only for TAs & non-confirmed accounts, makes sense. Showing other accounts' disallow tallies specifically to admins wouldn't be much of a stigma problem, but I agree with Niharika that it's just not very useful, especially because at least on enwiki, most of our disallow filters affecting (auto)confirmed users are actually for very boring things like using an institutional-only URL.

If this has to be a breaking change, I think that's okay, since it's not like a huge number of people were relying on this behavior to write out links by hand; it mostly occurred in templates. For now we've fixed PageLinks on enwiki by just using an external link, and we can do the same with others. I'm wondering if this is a case where the old links could be cleaned up by a maintenance script, though, given the long-term reliance on this behavior? It would be easy enough to get a bot approved to fix these on enwiki, but this affects all wikis, so I wonder if it'd be easier to handle server-side.

Are there AbuseFilter trips whose very existence is nonpublic? I thought it was only that with some the filter information (other than its name) is nonpublic. If so, I would think it's fine to show the disallow tally to anyone.

@kostajh I'm glad to know that, for sure, but I still think it would be better to limit things to a set time period even for admins/others who can block and trying to filter out inconsequential blocks. Partly because there's the risk of subtly prejudicing admins against users who have old blocks, especially with that yellow warning symbol, and partly because there's the risks of admins assuming that anyone can see this and therefore becoming more gunshy if they think the block they make will be broadcast to everyone with UserInfoCard enabled for the rest of time. (Admins are always bad at remembering which features are admin-only, and this one isn't even obviously so; people tend to assume that everyone's interface looks the same until reminded otherwise.)

I agree that that would be nice to get a commitment now (and will ping @cscott to ask if there's been any movement on that front), but in either case, this is not a blocker because the wiki will still work without this being resolved.

I think it can be done after setting up the wiki? All that'll break without it enabled is that __NIMI_SULI_O_AWEN__ will parse as plaintext rather than a magic word, which is a little annoying but not a huge deal.

As I explained at in T397999#11086062, this is not a problem, because the things you are listing are not what the extension exists to address. This extension is not trying to do away with the concept of pages having a single canonical title. It does one specific thing, which is alter the title that is displayed to the reader; there is no need for it change anything else.

There are any number of historical links, on-wiki, on the mailing lists, and indeed on Phabricator, referring to tokipona.wikipedia.org. Externally, here is an article by academic and Wikimedian Stanislav Kozlovsky referencing it; here is a blog post by someone else referencing it, and another.

License PR https://github.com/tbodt/mediawiki-tokipona/pull/4

(Is "stalled" correct for something currently blocked by another task? Please adjust as appropriate if not.)

I don't see how one could implement a pronouns feature in a non-language-specific way. Pronouns are inherently tied to the language being used. You may sometimes be able to infer that, say, someone using she in English probably uses elle in French, but they are not the same thing.

The fact that pages have a single canonical title is a fundamental limitation of MediaWiki, and not one that any extension, script, or combination of hacks will fix. But the MultiTitle approach solves most of the issues that this causes for Toki Pona, those related to not giving artificial weight to one of multiple valid page titles. So I'll second A_smart_kitten's request of whether this should be split off to a request for that, without prejudice against this task arriving at some more holistic solution eventually. As Tbodt alludes to, the documentation for getting WMF stewardship is rather vague for those of us who've never been through this process before.

Isn't the concern here more about people privately viewing deleted/suppressed revisions, than about actual undeletion/unsuppression, both of which are logged on-wiki?

Note that of the two non-ISO codes that don't run into this redlink issue, eml is a deprecated code and nrm is a valid code for a different language (Narom). However, that still doesn't explain the discrepancy, as als is a valid code for Tosk Albanian but still has this issue.

I agree with Tbodt's comment at the merged ticket that there should be some way to store previously-used date formats for DiscussionTools' reference.

Yes, for instance, a redirect from a misspelling shouldn't have its title kept, nor from a related topic, and probably also not a redirect from a historical name (especially if now disfavored). What this is meant to be used on is redirects where the name refers to the same thing as the target's name, and would be acceptable to use in normal speech in Toki Pona—that is to say, it could just as well be the title of the target page, but for the fact that it isn't.

@cscott Speaking just for the tokwiki half of this, rather than the general case that applies to hatnotes and similar, a WMF team's assistance in getting this enabled in prod would be more than welcome—even just an agreement in principle, conditional on tokwiki getting final LangCom approval. But I'll confess I don't really know much about the process of getting that stewardship. One dev did suggest I talk to the Language team, so, @Aaharoni-WMF, if you'll pardon the ping, could I ask if y'all would be interested in those 46 lines of code?

We considered this, but the problem is that the edit buttons would go to the wrong place. We could do editnotices and page protection to steer people in the right direction, but putting any additional hurdles between "edit" and "publish" vastly decreases people's interest in editing.

Summarizing and elaborating upon discussion with @bvibber and Tbodt (Tepo) at https://wikis.world/@tamzin/114753248831947961: Brooke says that "it might be tricky to get the redirecting page as a variable into the article without extra parser cache fragmentation" and suggests that it would be easier to set up something where the message is on the redirect, e.g.

= Foo =
#REDIRECT [[Foobar]]
{{PREAMBLE:code to display at top of target page, e.g. {{DISPLAYTITLE:Foo}} or {{redirect|Foo|other uses|Foo (disambiguation)}}}}

I agree that this is a good approach, since there isn't much practical difference between "Enabled across whole wiki but only used on target pages when a redirect is followed" and "Only used on redirects where it's needed, and displayed on target pages when they're followed". Enwiki could enable it by default for redirect tags like {{r mentioned in hatnote}}. Tokwiki could distinguish between redirects for valid alternate names (which should become the displayed title) and from things like misspellings, historical names, or related concepts (which shouldn't).

Rereading my above comment, it's worth stressing that the option for truly custom, language-specific pronouns is 1) IMO an absolute necessity for making the software approximate the range of human identity and expression, and 2) a nightmare of internationalization. For instance, possessive determiners and pronouns in most/all Romance languages aren't gendered according to the subject, so that field would have to be blanked out for anyone selecting those languages. And how does one convey, say, a suffix system like Hebrew has for possessives? The solution that comes to mind is orienting the data around variables, like we do with system messages, so "Possessive determiner" could default to "their $1" in English and "$1ו" in Hebrew, but that is very new-user-unfriendly. Maybe a graphical interface could simplify it though?

This is suboptimal as the interface language gender option is more about languages where there are gendered verbs/nouns, and pronouns are about how a person wants to be referred as

Here's an argument, though, for just getting rid of the "jumping" behavior. I was on the page https://en.wikipedia.org/wiki/Wikipedia:Requests_for_adminship, typing a reply to a comment in an RfA transcluded onto the page, and linked to https://en.wikipedia.org/wiki/WP:MONITOR in that reply. I opened that link in a new tab to make sure it redirected where I thought it did, and to verify how a sentence was worded. Well, it did, but the policy section in question is also on the main RfA page. So instead of being linked to there, I got dragged back down to the comment I was writing. Very jarring behavior, with no easy way to escape. At least in that context I knew the section the redirect ought to take me to, so I could go there to reread the sentence in question; but in other contexts it might be very much nontrivial to actually get to the anchor one was linked to.

This is very jarring behavior, and for a large page like AN/I on enwiki makes it actively harder for to comment in a thread where the evidence includes past revisions to the same page—or if you're warning someone for their behavior in the thread, and want to link to revisions. I encounter this problem pretty frequently as an enwiki admin, and have heard other admins mention the same issue, so I disagree with @Esanders that the workflow is "quite rare". Indeed, I thought to look up to this task because I ran into this problem for the umpteenth time while writing this comment. I do think Esanders is right that replying from an old revision is quite rare, but I think that makes the solution clear enough: As @MusikAnimal says, just don't auto-open the Reply Tool on old revisions.

@JJPMaster Well, consensus to request implementing this change. enwiki has no jurisdiction to compel any change to MediaWiki, and it's a bit irresponsible that the RfC implied it could. (That's on the nominator, not on you as closer, although I'd suggest a word other than "adopt" in the close for maximum clarity.) But as @Novem_Linguae said in the discussion, this should definitely be taken as a data point in favor of this change, and a pretty strong one at that.

Meantime, would it be possible for a sysadmin to reverse the protection of 1165 on enwiki? @suffusion_of_yellow has a good suggestion of giving stewards the right to undo it if accidental protection continues to be possible, but I agree with Pppery and Urbanecm that it should just not be possible.

There were a number of issues here, primarily someone having updated the RfD template without the requested notification, and then some ancillary issues as tend to arise when poking through old code that's migrated servers since it was written. After a rewrite to v2.0.0, all should be fixed.

@Beetstra The ../ vector works on all websites, if I'm understanding T352827#9391030 correctly, while URL-parameter-based tricks like ?realPage=BadPage will depend on the website in question. The way it seems to me, someone whitelisting a page or path is expecting to whitelist just that page or path. But the use of \b—which makes sense on the blacklist, where we want to match the whole site—has the opposite effect on the whitelist. So most of these URLs should have been using $ to begin with.

That makes a lot of sense, @matmarex, thanks. What about the URL parameters angle, though? To give a real example that seems ripe for exploitation, on enwiki the neo-Nazi site Metapedia is blacklisted, but \ben\.metapedia\.org/wiki/Main_Page\b is whitelisted. That allows a link like https://en.metapedia.org/wiki/Main_Page?oldid=479369, which in fact would lead readers to Holocaust denial.

Oh, postscript to my original post: Is the \S in my proposed regex necessary, or does the extension implicitly stop looking for a match when it hits whitespace? If the latter, a simple . would work.

I want to be clear, I hesitate to even call this a bug or a misconfiguration on the extension's end; it's just counterintuitive behavior for end users. With https://badsite.com/page/../../badpage, for instance, the extension is correctly saying "This does match \bbadsite\.com\b, so it should normally be blocked, but it also matches \bbadsite\.com/page\b, so it should be let through". That's all valid parsing of the regexen. The problem lies in how URLs actually work (or, tend to work on most websites), which is beyond the purview of a simple regex-based extension. (If this were, say, a profanity-matching extension, it would be working perfectly.)

This is all great long-term planning (seriously!) but is there a chance of making a stopgap, light-weight solution for just EmergencyCaptcha? Even if it's as simple as, I don't know, a page editable only by stewards (a few ways to implement that) that allows for a comma-separated list of wikis to have EmergencyCaptcha on on; have a script check it every 5 minutes or something. (Probably not ideal implementation, but just giving an idea of a fairly cheap implementation.)

I think the issue is, unless I'm misunderstanding, the user only gets the toast message if they've already clicked the X. So someone who thinks the X is to remove their email will never get the message saying that it isn't. I think removing by default is a good thing to consider. I'd think basically all users in 2023 have an expectation that any website they verify their email with still knows that email, without needing a prominent reminder.

@KStoller-WMF Hmm my only concern there, if we're thinking about the lowest common denominator, is that some users might think that the "X" is to remove their email from the account. I think the solution works in principle, though.

In T333723#8749093, @Legoktm wrote:

Is there something I'm missing?

Anecdotal reports from several users of concurrent issues logging in.

Meanwhile over here:

• failed: https://en.wikipedia.org/wiki/Yaqoob_Salem_Yaqoob
• failed: https://en.wikipedia.org/wiki/Shelagh_Stephenson
• worked: https://en.wikipedia.org/wiki/Clyde_Nelson_Friz
• failed: https://en.wikipedia.org/wiki/Thespidium
• failed: https://en.wikipedia.org/wiki/New_Brunswick_dollar
• failed: https://en.wikipedia.org/wiki/Jean-Louis_Fousseret
• worked: https://en.wikipedia.org/wiki/Osusz
• worked: https://en.wikipedia.org/wiki/Castlelyons_GAA
• worked: https://en.wikipedia.org/wiki/Head_(surname)
• worked: https://en.wikipedia.org/wiki/Water_polo_at_the_2000_Summer_Olympics_%E2%80%93_Men%27s_tournament

Persisting here for a few days now (Chrome on ChromeOS). Going to boldly set this as "Unbreak Now!" since the extension is currently unusable for many/all people.

I think this is due to one of the three users I had in the query being a high-edit-count user (>300k). That would make sense if the DB is applying the limit only after running the whole query, which I gather is how it works? For the purposes of what I'm doing, I can just exclude users with >100k edits, and that ought to handle it. But there's some use cases at least where that wouldn't be an option.

Since there will be some cases where no relevant log entries exist either, e.g. https://en.wikipedia.org/wiki/Special:Contributions/2803:D100:E080:306:787A:3962:E1E7:52EB, would there be any way to work from deleted contribs, at least for admins? Otherwise we have a situation where an LTA could cause a lot of disruption on a deletion-eligible page that someone else created, that page gets deleted, and now there's no way to use IP Info on the IP the LTA was using, short of undeleting a revision, which is something of a perverse incentive.

@Aklapper Sorry, I thought these steps were clear enough. The reason I think this is a bug is a) that it is inconsistent behavior and b) that there is thus no obvious way to download a PDF of an old revision (if such a thing is possible).

• At https://en.wikipedia.org/wiki/Foobar, "Download as PDF" links to https://en.wikipedia.org/w/index.php?title=Special:DownloadAsPdf&page=Foobar&action=show-download-screen
• But at https://en.wikipedia.org/w/index.php?title=Foobar&oldid=1077185943 it links to https://en.wikipedia.org/w/index.php?title=Special:Book&bookcmd=render_article&arttitle=Foobar&returnto=Foobar&oldid=1077185943&writer=rl

("Printable version" works as expected in both cases.)

I happen to have force-created an account on testwiki a while ago for T302771, so I just tried blocking it there. An autoblock was made, but there's no block notice if I go to edit logged-out... I'm guessing the difference is my IP has probably changed since I force-created the account a month ago, and by blocking the "last IP address" used by the account I force-created, it's really just blocking whatever IP I had the day I created it?

My first thought was something about capturing groups, but it also fails on (?:x)*. I then played guess-and-check with quantifiers, and found that it works fine up till (x){0,2729}, but anything past that fails. Hmm.