Change-Id: I97529b775d4db4f996c40395c891a0049d2e43c5

How is this different from the usual MediaWiki default bot deletions?

(In reply to comment #2)

How is this different from the usual MediaWiki default bot deletions?

Please (re-)read the comment. I explicitly explain this...

(In reply to comment #3)

(In reply to comment #2)

How is this different from the usual MediaWiki default bot deletions?

Please (re-)read the comment. I explicitly explain this...

Sorry, I've not been clear enough: I understand that the original code had some problems, for which reason some wikis didn't like it and it's not been run in ages, but I don't know exactly what: have you tracked down this?

(In reply to comment #4)

(In reply to comment #3)

(In reply to comment #2)

How is this different from the usual MediaWiki default bot deletions?

Please (re-)read the comment. I explicitly explain this...

Sorry, I've not been clear enough: I understand that the original code had
some problems, for which reason some wikis didn't like it and it's not been
run in ages, but I don't know exactly what: have you tracked down this?

No, the original script had no problems and nobody had a problem with it (nothing relevant today anyway). The "original script" is deleteDefaultMessages.php and still exists today.

It was run once globally around 2007 on all wikis.

There is nothing not to like about it. It is completely uncontroversial and trivial. It is no longer relevant today as the "MediaWiki default" system doesn't exist anymore. So running it again it pointless as it won't find anything (there are no more pages in existence last modified by "MediaWiki default" and no new ones will be added as the system doesn't exist anymore).

Around 2007 it had been a while since the PHP storage system was introduced, and that's when we ran this script.

Now in 2012 it's been a while since translatewiki has been introduced and local pages were copied to translatewiki by users. It still happens from time to time today that a language decides to change a message and first does it locally before importing to translatewiki. So we should probably re-run this every few years. But it is important we don't wait to long to avoid messages from becoming stale and being considered overrides when they are in fact stale.

And just like in 2007 we cleaned up system garbage, this time we clean up user garbage. And for the same reasons: To prevent the local versions from blocking updates.

Thank you for explaining why the other script has not been run and the different role of this other script; I'd appreciate if you could provide me some links that I could use as a reference for adding this information on wiki.

I think your summary is a bit idealistic ("MediaWiki default" is still blocked on one wiki), but I agree that this is considered standard cleanup on most wikis, that what you propose makes total sense and is very needed, and also that there shouldn't be big opposition.

(In reply to comment #6)

Thank you for explaining why the other script has not been run and the
different role of this other script; I'd appreciate if you could provide me
some links that I could use as a reference for adding this information on
wiki.

Example link:
https://li.wikipedia.org/w/index.php?title=Speciaal:Alle_berichte&prefix=&filter=modified

Dozens of messages there are still overridden locally eventhough it isn't really overriding it as the translation in translatewiki is the same as the local one.

This message
https://li.wikipedia.org/w/index.php?title=MediaWiki:Allmessages&action=history

... was last modified by a wiki user (it wasn't imported from the system, it was manually translated locally). Then some time later (possibly by the same wiki user) the same translation was provided to translatewiki and they accepted it and now all wikis have this version of the message. This is a success story!

I think your summary is a bit idealistic ("MediaWiki default" is still
blocked on one wiki), but I agree that this is considered standard cleanup
on most wikis, that what you propose makes total sense and is very needed,
and also that there shouldn't be big opposition.

That block is useless and could be (I don't know for sure) a good example of the part of the community that is being anti-foundation without knowing what they're doing.

That system hasn't existed for almost 5 years. So you can block all you want but that user, that system is dead and the block is completely pointless.

Also, that block and the opposition to it are no longer relevant. This bug is about a different measure and for different reasons.

The old system stored messages in the MediaWiki namespace exclusivel. The old system made localisation updates by editing those pages, we haven't done that for many years.

People blocked the system on some wikis to avoid losing their local overrides (as the system would edit the pages and replace the messages with the latest versions from translatewiki). Opposition to that is understandable if they prefer their own versions. And that's okay.

The system we have today, the system we've had for many years now doesn't do that anymore. We now store them on the server in i18n.php files and always consider the local MediaWiki namespace to be of priority. So when we update the software, we change them on the server. And the MediaWiki namespace will be a layer we no longer touch and remains on top.

The clean up script this bug is about does *NOT* replace local contributions and does *NOT* result in a visible change of messages.

It merely removes redundant pages leaving only the overrides.

So wikis that override a message (for example on nl.wikipedia.org they override messages referring to admins and call them Moderators instead) will not be affected, the overrides will continue to exist.

But if a message is changed locally (e.g. a better translation) and that better version is then submitted to translatewiki. Once it is accepted and deployed, we'll merge the central version and the local version so that future updates are visible (e.g. an even better version provided by the community).

(In reply to comment #1)

Change-Id: I97529b775d4db4f996c40395c891a0049d2e43c5

Landed in master.