In T274495#6822445, @Koavf wrote:

In T274495#6822219, @Billinghurst wrote:

But it is for Kindles. We want to make things as easy as possible for those who just want to download. I reckon just leave it.

There are many devices from many manufacturers that can process this content. Instead of giving an advertisement for a Big Tech abuser, just make it generic. If you have one of their proprietary jails, you know which file types it uses.

They were different versions of projects if I remember correctly, @MusikAnimal and EBernhardson did something new with their version 2. Where it belongs? <shrug>

But it is for Kindles. We want to make things as easy as possible for those who just want to download. I reckon just leave it.

If they want to build a work, wouldn't we encourage them to use the old PDF build tool.

@Xqt success! Thanks. Then just the usual hassle of parantheses in filenames and my forgetfulness of which ways they are handled, and fighting Commons existing filename blocking upload., but only after it has taken all the time to upload the file before it says YEAHNAH

Still failing

In T264788#6718839, @dom_walden wrote:

I compared the appearance of ebooks generated on test and production for a number of different ebooks, including those in the recently popular list.

I found a number of differences before and after this change. Many of these are not likely to be troubling to users. For example, margins between paragraphs sometimes differ, some text is aligned differently, some text is of different size.

Before	After

That may related to a missing class "ws-summary", I know that was added way back to ensure that things were generated properly with a table of contents. I remember nothing else. Never have found it where it is defined.

Some comments as a global abuse filter writer.

@Ankry @Zyephyrus @Mahagaja @-jkb- care to make comment for your community? To me it is imperfect though better than not having a link. My biggest concern is that it won't be obvious to users to where to add mulWS links.

@Xqt There seem to be quite a load of blockers within the system to this process, and think that they have been increasing in number, especially more recently. @Jdforrester-WMF may be able to comment or find someone who can.

They are the one static message from WMF messages—I am guessing they are translated at translatewiki

Have you looked to utilise @MusikAnimal 's AbuseFilterIRC

[Thought bubble too, not sure of whether it can be included or not.]

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