maybe @Giku can help here?

How about T172406: [Task] Improve the function for merging items before disabling clear flag?

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

In most cases, after a merge was performed the source item is redirected to the target item.

Amir @Ladsgroup just wrote a gadget for this purpose. Thank you, Amir!
Announcements:
https://www.wikidata.org/wiki/Wikidata:Project_chat#SearchAll_gadget
T48251#3485164

Just found around T118458: Echo did not trigger mention notification when user was linked; the problem reported by me above might be an instance of that bug also.

I just saw a post where I was mentioned but I didn't received a notification.
I was about to create a new bug for it, but found this one - I suppose this is the same issue or not really?

BTW in Mediawiki undoing multiple revisions by multiple users does not generate an automatic summary. This is a Wikibase-only related bug.

The core problem is the fact that Wikidata is poorly organized as a community and project. Per overall a big part of the work done is inefficient and counterproductive. At least the addition of descriptions/labels could and should be optimized. There are many users who acts just like bots, and using mass-editing tools on their own they add just by one description in a single language to series of items consisting of tens of thousands of items. For last month there are 4 human users who together made 3 Millions of mass-edits by adding just descriptions in their native languages (of them one user in 10 days made over 900,000 mass-edits to add descriptions). I can show you some large series of items where each item has over 50 consecutive edits made by one user in a short time span just to add descriptions/identical labels in several languages. I'm pretty sure that for our 30 Millions of items we don't want by 200 edits for each item just for addition of descriptions/labels.

This is very important for category/template items, where a pair label sitelink should be always moved together to not cause in future unneeded API errors/conflicts of non-unique label description between the two items (source and target).

Personally, I support implementing such a feature. But, if this will be included directly in core, probably there should be some limitations per user groups/experience, which should be discussed first.

Set normal priority, per Jheald's comment above and actual WD community needs and visions.

There already exists a gadget for searching, perhaps it could be improved to include the desired feature.

@Ricordisamoa: I'm fine with it if will be accepted and implemented. Just in case that suggestion will be rejected for some reason, anyway we'll need such a feature, so this ticket can be kept open meanwhile, I think.

To be clearer, there are templates which are concatenating variable values from articles with some predefined prefixes/sufixes from template to form a page title. For example:
https://en.wikipedia.org/w/index.php?title=Template:Infobox_French_commune
https://en.wikipedia.org/w/index.php?title=Template:Infobox_South_African_town
https://en.wikipedia.org/w/index.php?title=Template:Infobox_German_location
https://nl.wikipedia.org/w/index.php?title=Sjabloon:Infobox_Duitse_plaats_plus
https://ro.wikipedia.org/wiki/Format:Cutie_Localități_DE
https://ro.wikipedia.org/w/index.php?title=Format:CasetăSate
https://sr.wikipedia.org/w/index.php?title=Шаблон:Насељено_мјесто_у_Босни_и_Херцеговини

In T64014#3418906, @matej_suchanek wrote:

If this is to be an optional feature, an overhaul needs to be done to the script.

IMO this feature should be implemented ONLY as optional, because it is not always safe to import blindly any unliked value, and there could be imported some weird values, at least on some wikis. The user operating bot should decide himself if they want to assume such risk or not.

The feature of notifying client wikis about files nominated for deletion on Commons could be implemented as a Mediawiki extension as well, I think. To notify related WikiProjects on client wikis, more appropriate may be requests for bot work on individual wikis where the local community needs this.

Image preview could be useful for those who works on file page processing. Not only on Commons, en.wp has 850k files.

Bot task, not feature request.

AWB already has the feature to remove duplicated categories; you have to enable the "Apply general fixes" option. It also normalizes the categories.

Per https://phabricator.wikimedia.org/T112712#2941209

This sounds more like a bot task.
What's the problem to define this function in customized settings file and to load it each time when it's needed? I see at least two ways to do this job: Advanced settings -> new rule -> if page containns some category(ies), via a regex expression prepend or append whatever you want, including {{Creator}}; even simplier would be to this via "More" tab -> append/prepend combined with "Skip" tab -> Contains/Doesn't contain (a category name string). Or write a specific plug-in.

As Magioladitis said, this should be a bot task. At most could be implemented as a specific plug-in, but not in AWB core.

This idea is good.
There are many usescases around multiple major wikis, and I think Pasleim's harvest_template analogue already has such a feature enabled.
A patch is welcome.

Regarding the proposed patch(es) above.
While for individual tasks for personal use these changes may be ok (I also have locally several forks of some scripts:) ), in the current state it will not be accepted in gerrit by reviewers. Since we don't want *always* to treat any plain text in template parameters as a unlinked wikilink and to try to find their item, more code is needed here to define the new option as an optional feature.

ok, the examples from #0 are edits in 2014 and for them as you said it's expected to be as it is. But I saw such things on recent edits as well, on items which since 2014 were edited ~10-20 times, and is quite possible that these things are unrelated to the 2014 change. Or not?

@Mbch331, thanks, done.

I succeeded to change it - diff, check if the new query (converted via wdq2sparql) is good enough.

Oh, sure; you're right, @Esc3300. Thanks for catching that. I'll update the ticket.

Seems to be the same as T106456: Editing label and description simultaneously conflicts with existing items which have the new label and old description

But not in 100% of cases.
And it's difficult to predict for a big number of pages if their items should be merged or not.
If the interwiki links are very old, untouched for long time, actually there could be an interwiki conflict.

@Dereckson, more exactly what consensus do you want? Have you read all the above comments? The extension was enabled long time ago, without having an associated namespace activated. Something unacceptable.

Fixed (r/139766 r/352728).

Do we want to remove any empty sections, or only stadard ones (External links, References, etc.)? Removing *any* empty section might be problematic on small wikis, where may exist some kind of consensus to keep such sections.

To implement this, there should be added one more command line option (something like ~"-listok" / "-multiple") which will tell to script that is ok to harvest all listed values in a template parameter; but by default this should be disabled (it is not always safe, as Matej said above).

In T165249#3264786, @Ladsgroup wrote:

[...]Can you try by changing the description first and then adding en label?

do you mean in different edits? But why? In such case it should work certainly, otherwise the platform can be considered broken completely :)

@Multichill, yes, all data is sent in a single edit, like this one.
excerpt of the relevant code:

data = {'labels': {'en': u'%s' % enlabel,'it': u'%s' % itlabel},
     'descriptions': {'en': u'village in %s, Moldova' % ed, 'ro': u'sat din %s, Republica Moldova' % rd }}
item.editEntity(data, summary=u'...')

FTR, caused by such a 'wikilink':

@Urbanecm, seems that it wasn't merged yet.

Related to T72702: claimit and harvest_template - add another value for one property

this also affects 'harvest_template.py'.

Useful suggestion. Needed also for such common properties like "occupation" for people, and P150 (contains administrative territorial entity) and P1383 (contains settlement) for administrative subdivisions of countries.
I support implementing it.

This is even more confusing and disturbing for redirects from user pages to Flow user_talk pages. Just found such a case on [[:mw:]]. The URL in browser's address bar shows User namespace, but actually you are on User_talk NS. People may be hesitant to write posts on such pages. This should be fixed ASAP.

The problem still persist. Purge doesn't help.