john wrote:

Flooder group = bot right on meta wiki

As far as I can read my code it should just work. I'm copying all edit flags except EDIT_NEW and EDIT_UPDATE as is to the translation page edits.

I see it now. The bot flag is set manually by EditPage.php. I don't want add hacks like that into my code. Recategorizing to core bug.

In fact I can't even fix it, since allmost all translation edits go through the web API.

Example of what Niklas says: bot flag is not applied to translation unit edit either, and everything works when not using translation dialogs, e.g. right now

• b! 11:11 Terms of use/it‎‎ (2 changes | hist) . . (-6) . .

[FuzzyBot‎; Nemo bis‎]

b      11:11 (cur | prev) . . (0) . . Nemo bis (talk | contribs | block)

(Created page with "it") [rollback]

b!     02:57 (cur | prev) . . (-6) . . FuzzyBot (talk | block) (Updating

to match new version of source page)
N b 11:11 Translations:Terms of use/0-b/it‎ (diff | hist) . . (+2) . .
Nemo bis (talk | contribs | block) (Created page with "it")

(In reply to comment #4)

In fact I can't even fix it, since allmost all translation edits go through the
web API.

The web api supports the bot flag, but one has to explicitly specify it should be used, even if you have the bot flag. On the bright side, specifying bot will be quietly ignored if you don't have flag (So it could just always be specified), (but bot being quietly ignored without error isn't exactly documented, so probably shouldn't rely on it)

(In reply to comment #6)

The web api supports the bot flag, but one has to explicitly specify it should
be used, even if you have the bot flag. On the bright side, specifying bot will
be quietly ignored if you don't have flag (So it could just always be
specified), (but bot being quietly ignored without error isn't exactly
documented, so probably shouldn't rely on it)

This sound very illogical to me: an API edit is not made by a bot unless the client says so.

It should be: a client's edit is a bot edit if the editing user has a bit flag, unless that client specifically indicates its edit should NOT be marked as a bot edit. This should be consistent behaviour in all interfaces.

Bit flag = bot flag in comment 7 :/

Thehelpfulonewiki wrote:

Hmm, perhaps another thing to add to this - if I delete a page, that has, for example 50 subpages, is it possible to add a flag on to FuzzyBot so that it doesn't spam RC? I mean this hasn't been a problem yet, but it could be something to think about for the future.

(In reply to comment #9)

Hmm, perhaps another thing to add to this - if I delete a page, that has, for
example 50 subpages, is it possible to add a flag on to FuzzyBot so that it
doesn't spam RC? I mean this hasn't been a problem yet, but it could be
something to think about for the future.

This is another bug and it's already been fixed in trunk: the account will be created by the extension and so we'll be able to assign it to user groups.

This is similar to LiquidThreads bug 25455.

• Bug 41637 has been marked as a duplicate of this bug. ***

(In reply to comment #12)

• Bug 41637 has been marked as a duplicate of this bug. ***

Raising priority given repeated report by nl.wiki sysop. https://nl.wikipedia.org/w/index.php?title=Overleg_gebruiker%3ANemo_bis&diff=37505224&oldid=33957234
It would be nice if someone could look into it...

(In reply to comment #13)

(In reply to comment #12)
Raising priority given repeated report by nl.wiki sysop.

One dup filed six months ago is not a good reason for sudden high priority.

is there any update on where this is in the queue? There are multiple wikis who have complained and the bot is at risk of being blocked (and on two major wikis HAS been blocked) on these wikis because it isn't able to follow the local policies (which generally require a bot flag or a much slower edit rate and for it to respect a template denying access). Unfortunately with the bug the bot can even get the bot flag but still not be marked as such (The {{nobots}} question is separate).

(In reply to comment #15)

is there any update on where this is in the queue? There are multiple wikis
who
have complained and the bot is at risk of being blocked (and on two major
wikis
HAS been blocked) on these wikis because it isn't able to follow the local
policies (which generally require a bot flag or a much slower edit rate and
for
it to respect a template denying access). Unfortunately with the bug the bot
can even get the bot flag but still not be marked as such (The {{nobots}}
question is separate).

Its unclear which "bot" you are refering to, but if its just a normal bot, add the bot parameter to the api request....

Sorry Bawolff I should have been more clear.

It's the https://meta.wikimedia.org/wiki/User:Translation_Notification_Bot which I believe is actually a part of the TranslationNotifications extension. I actually had thought we should just be adding the api parameter too and I'm happy to open another bug but one about the same issue was marked as a duplicate of here (see comment 12 and 13) and it sounds like a couple people were told that the intention was to not make changes to the extension and to wait for this bug.

My apologies, I thought you meant some random normal bot.

The history of this bug is exceedingly silly. Yes, MediaWiki core is not perfect and EditPage.php could certainly use love, but there's no good reason that the bot flag shouldn't be set when making these edits. This should be a one-line fix.

Fortunately, bug 41637 has been re-opened, so I'll just go complain over there.

There are issues getting conflated here.

• bug 33461: abstraction issues in MediaWiki core's EditPage.php

• bug 41637: bot flag not being set in Extension:TranslationNotifications

• bug 49071: bot flag not being set in Extension:Translate

As I understand it.

In my opinion, every extension or other piece of code should using the MediaWiki API to make edits, so the abstraction issues in EditPage.php really shouldn't be relevant insofar as the bot flag is concerned.

(In reply to comment #20)

There are issues getting conflated here.

• bug 33461: abstraction issues in MediaWiki core's EditPage.php

• bug 41637: bot flag not being set in Extension:TranslationNotifications

• bug 49071: bot flag not being set in Extension:Translate

As I understand it.

In my opinion, every extension or other piece of code should using the
MediaWiki API to make edits, so the abstraction issues in EditPage.php really
shouldn't be relevant insofar as the bot flag is concerned.

Most extensions do not use the api to do edits on the php side (they do use it if the edit is coming from js side). Calling the api internally from the php side is rather hacky curently (unless things have changed).

(In reply to comment #21)

Most extensions do not use the api to do edits on the php side (they do use
it if the edit is coming from js side). Calling the api internally from the php
side is rather hacky curently (unless things have changed).

The MediaWiki API has sanity checks for user permissions, bot flags, blocks, etc. Duplicating this logic internally is senseless.

(In reply to comment #22)

(In reply to comment #21)

Most extensions do not use the api to do edits on the php side (they do use
it if the edit is coming from js side). Calling the api internally from the php
side is rather hacky curently (unless things have changed).

The MediaWiki API has sanity checks for user permissions, bot flags, blocks,
etc. Duplicating this logic internally is senseless.

Like said, calling the WebAPI internally is pita and hence nobody does it. There is even a bug open demanding that nobody does that in a certain way because it messes up things.

(In reply to comment #20)

There are issues getting conflated here.

• bug 33461: abstraction issues in MediaWiki core's EditPage.php

• bug 41637: bot flag not being set in Extension:TranslationNotifications

• bug 49071: bot flag not being set in Extension:Translate

As I understand it.

You're misunderstanding it. The whole point of this bug is that there is code in EditPage that should be shared between the Edit API and EditPage ("In fact I can't even fix it, since allmost all translation edits go through the
web API."). So your advice to use the WebAPI does not solve the problem.

(In reply to comment #24)

You're misunderstanding it. The whole point of this bug is that there is
code in EditPage that should be shared between the Edit API and EditPage ("In
fact I can't even fix it, since allmost all translation edits go through the
web API."). So your advice to use the WebAPI does not solve the problem.

Where is the specific code in the Translate extension that's making these edits? I tried to trace it via specials/SpecialTranslate.php.

• Bug 49071 has been marked as a duplicate of this bug. ***

(In reply to comment #25)

Where is the specific code in the Translate extension that's making these
edits? I tried to trace it via specials/SpecialTranslate.php.

I think the relevant line is https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/Translate.git;a=blob;f=utils/TranslationEditPage.php;h=7b10e32150650b34dc22a40e206a86c83b3c4e14;hb=HEAD#l179 .

Please be cautious about cloning bugs/marking them easy/etc. if you're not sure you understand the issues.

(In reply to comment #27)

Please be cautious about cloning bugs/marking them easy/etc. if you're not
sure you understand the issues.

Why did you mark bug 49071 as a duplicate? This bug is about MediaWiki core. Bug 49071 is about the Translate extension specifically, which seems to be using the MediaWiki Web API and is not setting a bot parameter. What am I missing here?

As Niklas said earlier:

"I see it now. The bot flag is set manually by EditPage.php. I don't want add
hacks like that into my code. Recategorizing to core bug."

He said the proper fix to this is in core, rather than a workaround in every extension. Siebrand said:

"It should be: a client's edit is a bot edit if the editing user has a bit flag,
unless that client specifically indicates its edit should NOT be marked as a
bot edit."

I am inclined to agree with both of them. This means changing the behavior of the bot parameter for https://www.mediawiki.org/wiki/API:Edit such that it overrides the account's flag (of course, regular users can not use the bot override), rather than making bot accounts always say "Remember, I'm a bot!" on every request.

I don't think it's appropriate to defer fixing a real issue (edits not being marked with the bot flag) in favor of potential future optimizations to EditPage.php, especially as the Translate extension, as far as I can tell, is using the MediaWiki Web API (either with JavaScript or with PHP that posts to /api.php), both of which already support fixing the underlying issue that was reported here with a trivial fix.

(In reply to comment #30)

I don't think it's appropriate to defer fixing a real issue (edits not being
marked with the bot flag) in favor of potential future optimizations to
EditPage.php, especially as the Translate extension, as far as I can tell, is
using the MediaWiki Web API (either with JavaScript or with PHP that posts to
/api.php), both of which already support fixing the underlying issue that was
reported here with a trivial fix.

I'm not trying to prevent anyone from submitting a workaround to the Translate extension.

I'm simply saying I agree that core should be changed so such workarounds will no longer be necessary.

Change 575628 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] [WIP] EditPage: Allow bot users to mark edits as non-bot in the UI

https://gerrit.wikimedia.org/r/575628