What would be the purpose of retaining them? In the scheme of things these wikis are tiny and the space and infrastructure debt would presumably be negligible, so the issue would be the value of keeping them as separate copies.

@dom_walden that is part of each wiki's MediaWiki:Gadget-WSexport.js and in production at enWS it is now

//wsexport.wmflabs.org/wsexport/tool/book.php

Actually can we please get the documentation updated in to remove pwb.py. [I had removed it from my commands.]

Duh python3

duh python3

Another example of requirement for people spoofing IP addresses

In T258484#6354085, @Soda wrote:

@samuelguebo You probably need to create MediaWiki: Proofreadpage index template and MediaWiki: Proofreadpage index data config according to the instructions down the extension page (or copy over the ones at https://en.wikisource.org) and then create a new Index page. That new Index page should show up on Special: IndexPages.

@ifried There are 6 works in that series that have page 62. Can you please drill down a little further at least on the wiki so we can see how the same links are working in html. Thanks.

Can I comment that this is one user generating this discussion, and at this time it is an unsupported issue. The rights as currently set have been in place for 12 years, and were what would have been considered a consensus at that time. There is no demonstrated issue or community reports of this required change.

While I would agree that it is a better solution, I would think that impacted wikis should be involved in the decision itself,

The addition of Wikisource was purposeful and if you had waited a minute or two while I completed the complementary paperwork, and we can get the ping in place, get some people aware, and then we can remove.

should this be tagged to Equivset ?

I did recently suggest in T253367 as means to look at the abuse of some of the unicode textual representatives and how we might be able to use anitspoof as a futher means to exclude as usernames or as certain article names.

Has ULS been implemented suitably? Should this be a UniversalLanguageSelector issue?

@Jdlrobson With the change I have noticed that the css class "indented-page" is now quirked

In T238285#5821312, @MusikAnimal wrote:

I ran into this when I was unable to block https://en.wikipedia.org/w/index.php?target=Printf%28%22Herro+World%22%29%3B&title=Special:Contributions. All the user links in revision histories, etc., use path-style parameters which produce a broken link such as Special:Block/Printf("Herro_World");. Until this is fixed, we can use AbuseFilter to disallow creation of usernames/pages with semicolons.

@WeeJeeVee Oh, you are using the enWS script https://en.wikisource.org/wiki/MediaWiki:TemplateScript/proofreading.js which is based on TemplaetScript. I have made the change requested and it should be okay now. If you have further issues or additional characters into that script, then please make a request to that talk page, or ask at enWS's administrators' noticeboard

I have seen it previously in English language works, though not often. Usually with these things I add them to clean-up scripts through the regex clean up tool TemplateScript. I haven't played with your OCR cle3an up tool, though think it should be possible to add another character to that.

So this seems to be that we should consider renaming, and it becomes about picking a set of terms for the next many years. I am not convinced that block is the right term, it already has other meaning and will that just be confusing?

@bd808 think that it falls somewhere in the middle. I was finding fails, then I found some passe as I was faffing around trying fixess. At which point, I think that I shrugged and thought that I didn't know enough. Apart from that it was 3+ years ago. In the end, the important links are fixed, and it is just the chook scraps that are left.

In T254045#6179000, @Bugreporter wrote:

Adding a character to $wgInvalidUsernameCharacters will not affect existing users. Still, I oppose adding it.

If a character is to no longer be allowed, then the best solution is not to use the title blacklist, which is just an ugly hack.

@Pathoschild @MarcoAurelio noting the above comments about meta.toolforge.org

Wouldn't the community be required to demonstrate a consensus to change to local uploads rather than Commons uploads?

Are we right to change these over?

In T224802#5970934, @Tacsipacsi wrote:

I examined the logs for a few examples of mine (a few months ago), and it seems that AbuseFilter kicks in for old revisions as well, so it seems for me that the only solution is to have the OTRS tag not have been added ever, which is impossible, of course.

FWIW if an abuse filter is causing false positives, then the abuse filter should be modified as the first point of call

Probably me misunderstanding, but as enwiki is not a global abuse filter wiki, why would you expect a change at enwiki?

I am surprised that this isn't part of the roll-out documentation that Page: ns is meant to be subpages. It shouldn't need a consensus, it was a miss during creation.

I would just give it the same behaviour as the "filter revisions" on the history page => collapsed

Thinking a little broadly rather than my initial issues for looking for problematic editing outside of one wiki, to what and how one might wish to quickly limit/focus searches.

• language based — show me those wikis where the native language is Spanish
• sister/domain based — show me these results across all wiktionaries or all wikimedia domains

Existing authorisation is working for me at this time (billinghurst). Adding the OAuth to my alternate account worked too (sDrewth).

Is there a problem with the existing means to do this ?

If you are just focusing on the main namespace output this can be done now. There are just consequences [downsides or errors to manage.]

talking 2++ hours later

1. As we discussed in enWS, your preview positioning is set in preferences, you can ignore all components of the skin, none of the skin matters.
2. There is globalpreferences, on the EDITING tab where you set your preferred global default for preview positioning Show preview before edit box
3. There is a local wiki preference where you can override your preferred global (same text)
4. If your globalpreference changed the most likely explanation is the you did it, maybe without realising you were in your globalpreference
5. If you can set it and it saves and it propagates, then all this conversation is not required

@Edd0408 These edits do not seem to be useful or correct, can I suggest that you desist, or seek guidance in the use of phabricator

this is not a duplicate; that assessment is incorrect

this is not a duplicate; that assessment is incorrect

this is not a duplicate; that assessment is incorrect

Issue has occurred at enWP again, so will be running the bot through. Just amending the script line to be

then we can just have the link set to c:Commons:GNU Free Documentation License, version 1.2 that will work, even from Commons.

Well something quirky is happening. That was the url that the system delivered from the search at the time. Good now. MA knows that I have been having other time out issues with spambot urls, so I am just going to have to keep a watching brief.

I have created the loginprompt text as indicated above. It is in English.

In T247432#6055254, @bd808 wrote:

In T247432#6054372, @Billinghurst wrote:

We also have four others to be managed, all easy conversions

• petscan    https://petscan.wmflabs.org/?psid=$1
• quarry    https://quarry.wmflabs.org/$1
• utrs    https://utrs.wmflabs.org/appeal.php?id=$1
• wmfdashboard    https://outreachdashboard.wmflabs.org/$1

These 4 are not Toolforge tools. They are instead Cloud VPS projects behind a different web proxy. These hostnames are not changing at this time. We have long term plans to replace the *.wmflabs.org naming with *.wmcloud.org, but that will be done as a separate project.

Noted to https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team#Suggested_that_direct_account_creations_be_turned_off_for_TESTWIKIDATA

Can someone please add the documentation of this to https://www.mediawiki.org/wiki/Extension:SyntaxHighlight and the requisite fix. The fix should be clear and evident. Thanks.

We also have four others to be managed, all easy conversions

Also for archivebot.py jobs the script fails completely. I am getting this error on the grid

@Krinkle it is my understanding that deprecated font tags will be supported by the browsers,, is that not the case?

Having the plural itself would be an advantage, and maybe sufficient to change the thinking. Having the word "ALL" to lead would be problematic as nobody will find the sisters by the typing lookahead function, so if you do need all then "WIKISOURCES-ALL" would be okay.

It looks like a new item was created by whatever you were doing if I look at
https://www.wikidata.org/w/index.php?title=Q87748026&action=history
which was created by you and was moved by you to the other item
https://www.wikidata.org/w/index.php?title=Q13391335&action=history

As we are going to a continuous hosting of wikimanias, and are meant to be importing 10+ years of works it should give indications of what and where we are seeing historic viewing.

I have created a simple message within`Mediawiki:Loginprompt` that has a link to meta's create account page.

Did this get discussed at any point?

@Aklapper I did the task and had it fixed at the time, left as others were continuing part of the conversation re the consequences.

Semantically speaking ...

I would think that we would add the comment that this is known for about 10 years and English wikisources have been managing this using placeholders like
https://en.wikisource.org/wiki/Template:Nopt

In T240858#5890290, @thiemowmde wrote:

@awight, I believe you will find https://gerrit.wikimedia.org/r/570376 quite fascinating, if not funny. As it turns out one of the chunks of code that motivated this ticket here is not even needed.

In T172953#5842060, @Samwilson wrote:

@Billinghurst: I agree, and I think the wider topic of Index page's metadata and how it works with Wikidata etc. is going to take some greater thought. This task is specifically not looking at any of that, and focussing only on an easier way to create a <pagelist /> so that editors don't have to have multiple tabs and files open when doing so. Do you think the proposed system sounds good for this? i.e. viewing each page in a zoomable popup etc.

In T49544#2264126, @Jdforrester-WMF wrote:

Not allowing block elements in references is absolutely intentional; I'm Declining this.

Tagging major functional changes like this as "Easy" is pretty disrespectful to people, given that it's a huge change and reversing a very long-standing intentional choice.

Sorry that I didn't see this until now, especially to @Aashaka.

I find that if there is a good {{book}} template that this is pretty easy with the gadget in place, though find that the triangle of WS <=> Commons <=> Wikidata could really be tightened in a push <-> pull data to make sure that each aligns. That is truly problematic when each does not have maximum data.

To note that we do have a redirect in place from ngWM to ngWP — a closed wikipedia.

TOKEN FOR RICH!

Which user_right is required?