I did it a week ago but forgot to update the task, lmao.

In T309328#8382746, @valerio.bozzolan wrote:

@Vituzzu before rollbacking my changes in the Task I created, can you be so kind to explain why you don't agree with that assertion? The assertion was: Open proxies are blocked to fight spam, from anonymous users, as well from users with just the e-mail self-verified.

In T309328#8382082, @valerio.bozzolan wrote:

@Vituzzu: Yeah but also blocking autopatrol-flagged and bot-flagged users from an IP-block-range would also merit a proper discussion, which I have not found.

This is not a technical matter but rather a *very wide* policies-related change which requires proper discussion on the relevant projects.

My replies:

1. a combination, with the idea of tackling both wikis where the spam is in language which is the one of the wiki and a foreign one. Also, wikis where spam is a huge % of overall edits (e.g. mediawikiwiki) and those where it is not (e.g. some major wiki), also some wikivoyage should be included given that wikivoyages actually welcome "spammish" behaviors.
2. one for each combination of the above mentioned "dimensions" (EN/non-EN, spammed/non spammed, different projects) would be be maybe 8 or 12
3. yup
4. another round wouldn't be needed, theoretically, but it probably depends on the first round outcome
5. 90, but let's reconsider it halfway, within, let's say, 45 days
6. metrics seems to be fine

The stewards appear to be in a battle mentality against long-term abusers.

It's really a shame that phab doesn't allow the GIFs required to express how disappointing this sentence is.

Is T278445 related?

In T278445#6945790, @Izno wrote:

I think this is probably covered somewhere or another under the Math project already, but tag so that one of those sorts can double check.

I went through a series of examples and I think the reason is pretty odd: this happens when an invalid address is put in "your email address" field in special:contact

Indeed, here's a recent example: P13762

It's a different string. Namely in this case is a wrongly encoded Cyrillic string. This ticket contains users' IP (similarly previous ones) so I'm not inclined to move it in a queue you can access. Instead we can apply a security policy and I'll paste it here.

In T110329#4680123, @Deskana wrote:

@suffusion_of_yellow, @Xaosflux, thanks to both of you for the extra information. As you say, there's no way to be conclusive here, but it does seem there's a link to the visual editor.

I'm really surprised there's a link here, because those settings are (intentionally) buried, but there you are. I wonder if people are reading some kind of tutorial published by a third-party on how to get spammy pages into Wikipedia, or if it's one person (or a small number of people) sockpuppeting, or something else? (I'm speculating, it's not really important right now.)

You noted the edit filter that's preventing this, which seems to solve the immediate problem. I also see that you've changed the system messages on the English Wikipedia to warn people that adding this may prevent them from saving, which I very much appreciate. In terms of changing other things, is there something else you have in mind?

Same happens with my Irclogbot only at es.wiki (out of the five wiki it operates on). The bot just read abuselog from api without editing, confirming given "diagnosis" above.

"blockip-legend" is no longer localized, at least for Italian

In T107036#3664366, @Ladsgroup wrote:

Can I ask what do you see incorrect in the new interface?

No ways to opt out on user basis?

Some more detail: https://it.wikipedia.org/wiki/Speciale:FiltroAntiAbusi/7 sometimes start catching edits from autoconfirmed (I once added a redudant clause for bots, which obviously didn't solve anything). Here's an example: https://it.wikipedia.org/w/index.php?title=Speciale:FiltroAntiAbusi/examine/201858102&testfilter=(article_namespace == 0) & (!("autoconfirmed" in user_groups) | (user_editcount < 20)|!("bot" in user_groups)) & !(user_name in article_recent_contributors) & (old_size > 0) & !("{{coord" in added_lines) & (rcount("http[s]?://", string(added_links)) > rcount("http[s]?://", string(removed_links))) & !(count(" count(" though the edit was caught https://it.wikipedia.org/wiki/Speciale:RegistroAbusi?wpSearchUser=Azazello&margherita&wpSearchTitle=Alan Marshal&wpSearchFilter=7&wpSearchEntries=0

I could use some translations for the following list of text.

• External links modified

Collegamenti esterni modificati

• Hello fellow editors,\n\nI have just modified {linksrescued} external links on [[{namespacepage}]]. Please take a moment to review [{diff} my edit]. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit [[:m:InternetArchiveBot/FAQ|this simple FaQ]] for additional information. I made the following changes:\n{modifiedlinks}\nPlease refer to the FaQ for information on correcting errors with the bot.\n\nCheers.

Gentile utenti,\n\nho appena modificato {linksrescued} collegamenti esterni sulla pagina [[{namespacepage}]]. Per cortesia controllate la [{diff} mia modifica]. Se avete qualche domanda o se fosse necessario far sì che il bot ignori i link o l'intera pagina, date un'occhiata a [[:m:InternetArchiveBot/FAQ|queste FAQ]]. Ho fatto le seguenti modifiche:\n{modifiedlinks}\nFate riferimenti alle FAQ per informazioni su come correggere gli errori del bot\n\nSaluti.

• External links found that need fixing

Collegamenti esterni che necessitano di correzione

• Hello fellow editors,\n\nI have found one or more external links on [[{namespacepage}]] that are in need of attention. Please take a moment to review the links I found and correct them on the article if necessary. I found the following problems:\n{modifiedlinks}\nWhen you have finished making the appropriate changes, please visit [[:m:InternetArchiveBot/FAQ|this simple FaQ]] for additional information to fix any issues with the URLs mentioned above.\n\nThis notice will only be made once for these URLs.\n\nCheers.

• Gentili utenti,\n\nHo individuato uno o più collegamenti esterni su [[{namespacepage}]] che necessitano di attenzione. Per cortesia verificate i link trovati e correggeteli se necessario. Ho trovato i seguenti problemi:\n{modifiedlinks}\nUna volta completate le modifiche necessarie visitate [[:m:InternetArchiveBot/FAQ|le FAQ]] per sapere come correggere eventuali problemi coi link in questione.\n\nQuesta notifica sarà data una volta sola per questi URL.\n\nSaluti.

• Trouble archiving links on the article

• Problemi durante l'archiviazione dei link sulla voce.

• Hello. During the archive process, the archive returned errors for one or more sites that I submitted for archiving.\nBelow, I have included the links that returned with an error and the following error message.\n\n{problematiclinks}\nIn any event this will be the only notification in regards to these links, and no further attempt will be made to archive the links.\n\nCheers.

• Ciao, durante il processo di archiviazione l'archivio ha restituito degli errorei per uno o più siti.\nDi seguito i collegamenti che hanno dato un errore con l'errore restituito.\n\n{problematiclinks}\nIn ogni caso questa sarà l'unico messaggio d'errore per questi specifici link e non ci saranno ulteriori tentativi d'archiviazione.\n\nSaluti.

• {link} is found to be dead. Recommend adding {newarchive} to the original URL.

• {link} è interrotto. Si raccomanda l'aggiunta di {newarchive} all'URL originale

• {link} is found to be dead. No archive was found.

• {link} è interrotto e non ne è stata trovata una versione archiviata.

• {link} is considered to be dead, however has been found to be alive. Recommend removing the dead flag from the URL.

• {link} è marcato come interrotto, tuttavia sembra funzionare. Si raccomanda di rimuovere la marcatura "interrotto" dall'URL.

• Added archive {newarchive} to {link}

• Aggiunta del link all'archivio {newarchive} per {link}

• Replaced archive link {oldarchive} with {newarchive} on {link}

• Sostituzione del link all'archivio {oldarchive} con {newarchive}su {link}

• Corrected formatting/usage for {link}

• Correzione formattazione/utilizzo di {link}

• Added {{tlx|dead link}} tag to {link}

• Aggiunta di {{tl|collegamento interrotto}} su {link}

• Removed dead tag from {link}

• Rimozione del tag link interrotto da {link}

• Modified source for {link}

• Fonte modificata per {link}

• {problem} with error {error}

• {problem} con errore {error}

• Rescuing {linksrescued} sources and tagging {linkstagged} as dead.

• Recupero di {linksrescued} fonti e segnalazione di {linkstagged} link interrotti.

• Notification of errors encountered when attempting to archive links

• Notifica di errori durante l'archiviazione dei link

• Notification of altered sources needing review

• Notifica di fonti modificate che necessitano di una revisione

In T71168#3371728, @JMinor wrote:

I assume the thinking was that some summary is better than none, and that on mobile anything we could do reduce the amount of typing would encourage people to provide summaries, when they otherwise might not. Again, this predates me, so I can only guess.

Definitely a bad idea, users no longer rely upon summaries, assuming defaults ones are simply fake.

In T71168#3332049, @Deskana wrote:

In T71168#3324893, @JMinor wrote:

Although the expert opinion expressed by Bongwarrior is valued, I'd be curious if there is any actual evidence that these are in any way worse for curation than an empty text box.

Yes, this seems to be a bit jumbled up. The sentiment seems to be "Because the canned edit summaries are used with bad edits, the canned edit summaries are causing bad edits." This is the post hoc ergo propter hoc fallacy, as Murph9500 pointed out in the discussion on enwiki. The onus is not on us to disprove a fallacious argument.

Now, there is a point here that is logical: there's not much point in having the canned edit summaries there if they're not being used properly. I did some very quick data analysis on edits with canned edit summaries, and:

• 51.4% were good edits
• 49.6% were bad edits

The interesting thing was that 36.9% of the good edits had misleading canned edit summaries; the edits themselves were good, but the summary chosen didn't really match what the edit changed.

I'd be interested to compare this to non-canned edit summaries. Specifically, are 49.6% of all edits with an edit summary bad? I expect not, and that generally that is much lower. This would seem to suggest that canned edit summaries are bad, but there are confounding factors, such as it being possible that it's more of a reflection on mobile editing than canned edit summaries. On the other hand, over half of them are helpful edits, and nearly two thirds of those are correctly tagged. This would seem to suggest that canned edit summaries are good. It's also unproven that canned edit summaries are helpful at increasing the edit success rate.

In short, the quick data analysis I performed is inconclusive as to whether canned edit summaries are bad or not. There are reasons to suggest they might be bad, and reasons to suggest they might be good.

I really don't know what to suggest.

In T71168#3324893, @JMinor wrote:

Thanks for bringing this discussion on EN to our attention @TheDJ

Although the expert opinion expressed by Bongwarrior is valued, I'd be curious if there is any actual evidence that these are in any way worse for curation than an empty text box. But I don't believe we'll have the time to investigate objectively and across languages whether this is systemically problematic. So, in this case I'd lean to deferring to these en.wp editor's sentiment and remove them.

Ideally @Jdforrester-WMF or other members of the Editing or Collaboration team would weigh in here as well, since this technically falls in their jurisdiction, but given the "unique" arrangement of apps I'll work this though our process as is.

In the meanwhile I used this trick: https://wikimania2016.wikimedia.org/wiki/MediaWiki:Titleblacklist

I think it can safely re-enabled on significantly smaller wikis even prior to any investigation. Or better, IMHO, it can be disabled just on a limited set of bigger wikis.

Also bots might need to use different namespaces. Anyway piping them locally shouldn't be so hard, though it should be supported explicitly by pywiki/AWB scripts (basically ignoring any further <siteinfo> section).

I eventually managed to fix it: WMF's install actually uses VARBINARY(255) instead of VACHAR(255) (as for mediawiki's default) for page_title column. An ALTER table 'page' CHANGE COLUMN 'page_title' 'page_title' VARBINARY(255) NOT NULL COLLATE 'binary'; did the trick. I'll go on testing around and I'll eventually change mediawiki.org's mwdumper guide.

I'm still puzzled, it seems to be a true 4byte char trying to be insert in a column whose encoding is 3byte.

I was importing latest it.wiki's xml pages' dump, namely itwiki-20161201-pages-meta-current.xml.bz2 (MD5 checked). I think you can more efficently look for the relevant line in dump than me, otherwise I'll try. It seems to encounter a https://chars.suikawiki.org/char/1050A char needing a fourth byte to be encoded. I've subscribed Ori since he seems to have already dealt with a similar issue in another context.

People can simply register to hide their IPs, people with privacy issues can ask relevant revs to be hidden/suppressed. Honestly I don't see pros while I see the biggest cons ever: the end of countervandalism as we know it.

In T148274#2735263, @Legoktm wrote:

In T148274#2735224, @Vituzzu wrote:

Will virtual namespace support special:Linksearch?

Neither would - Special:LinkSearch is for external links, and the ISBNs link to Special:Booksources, which is on the same wiki.

Will virtual namespace support special:Linksearch?

I asked for another screen of special:version since it doesn't include any fancy infobox.

Maybe I wasn't able to explain myself. Current global policy sets a limit for technical reasons. I think this technical background is no longer valid then my RFC here. Is there a technical limit upper limit to edit rate? Is maxlag default value enough to prevent techinical issues?

No pb, I'll try improving description.

See the title: I don't use -sul option but still the bot welcomes autocreated accounts.

Ok, so what's the place to have a technical feedback about this particular global policy which should affect *any* wiki?

In T141730#2550533, @D3r1ck01 wrote:

In T141730#2550529, @Vituzzu wrote:

I'd suggest leaving a note in mailing list(s) about this kind of task *before* closing in order to have more feedbacks. If aware, I would had strongly supported Glaisher for 2 ofc.

True. I am just seeing it now. I suggest it should be reopened for people to give feedback. Thanks

I'd suggest leaving a note in mailing list(s) about this kind of task *before* closing in order to have more feedbacks. If aware, I would had strongly supported Glaisher for 2 ofc.

In T137923#2384116, @DoRD wrote:

In T137923#2384109, @Vituzzu wrote:

It seems there's something wrong with APIs. popup returns "BLOCKED, LOCKED" for every user account.

However, if an account has no live edits, no status is shown at all.

It seems there's something wrong with APIs. popup returns "BLOCKED, LOCKED" for every user account.

So it happens with all options. Dunno if it's related but now I see "warn" sub-options even if warn is not choosen.

In T136647#2343119, @kaldari wrote:

@Dereckson @Vituzzu: The only reason it's sorting correctly currently is due to manual hacks on each article. For example, at https://it.wikipedia.org/wiki/Apollo_9:
[[Categoria:Programma Apollo|Apollo 09]]
Once Italian Wikipedia is using uca-it, we'll be able to turn on numerical sorting for it, so that the hacks won't be needed any more.

In T136647#2343075, @Dereckson wrote:

Numeric collation

Currently, the default uppercase collation sort correctly numbers, as shown on https://it.wikipedia.org/wiki/Categoria:Programma_Apollo.

The uca-fr collation sorts correctly numbers too, as shown on https://fr.wikipedia.org/wiki/Catégorie:Mission_Apollo

The question is if uca-it will also sort them correctly, to avoid 1 10 11 12 13 2 3 4.

In T130234#2234953, @Halfak wrote:

We should likely not even display a diff if the parent revision is unavailable. If we wanted to be a bit more intelligent though, we could compare to the most recent non-deleted parent. If we're doing that in Wikilabels, we'll want to do that in revscoring too.