fixed. The bug was caused by the recent redesign of the wiki replicas.

I expect that this issue can be fixed by adding

observer.disconnect();

at the appropriate position in MediaWiki:Guidedtour-lib.js

I experience the same problem as Zoranzoki21 since January 23.

I've written a new service to check constraints on unsaved statements: https://tools.wmflabs.org/plnode/
If a bot or tool operator plans to use it, please inform me.

@Sebastian_Berlin-WMSE I implemented your patch on test.wikidata but it does not seem to work. Do you know how to improve it?
Otherwise I think we can proceed with the hack by @Ladsgroup.

To make it a bit clearer, I've set up a demo tour: https://test.wikidata.org/w/index.php?title=Q1027&tour=wbtest
The 3rd window of the tour should be attached to the property input field but it isn't.

likely the same bug as in T212633.
If you edit a description in Cantonese, the description is saved on Wikidata under zh-yue instead yue.
yue is the content language of zh-yue.wikipedia.org.

In T212633#4849103, @Addshore wrote:

Will edits that have already happened need cleanup?

This can be changed in https://www.wikidata.org/wiki/Template:Request_for_deletion.
But it should first be disussed on the Wikidata Administrators' noticeboard or project chat because using {{Q|}} creates varying titles depending on the UI language which makes linking to sections impossible.

It is possible to remove the tokipana terms by undoing the edits in which they were added https://www.wikidata.org/wiki/Special:Diff/716262791 .

Instead of fixing the gadget it would be more elegant if T192188 could be resolved.

try

SELECT term_type AS term, term_text, term_language FROM wikidatawiki_p.wb_terms WHERE term_full_entity_id = 'Q4855000' AND term_type IN ('label', 'description');

term_entity_id is no longer written.

Normally, there are 7 "popular items".
Today's update has only 2 items because the Wiki replicas on Toolforge have a lag of many hours.

done

Nevermind, I did not know that term_entity_id is no longer written.

all items created after March 14 are missing in the wb_terms replica table.

I can not use EXPLAIN:

ERROR 1345 (HY000): EXPLAIN/SHOW can not be issued; lacking privileges for underlying table

The first query I could rewrite to SPARQL and execute now on query.wikidata.org.
The second query I tried to rewrite with NOT EXISTS instead of NOT IN but did not speed up. I need to have T114904 been resolved. Till then, I deactivated the script which calls this query.

The problem is related to overlays. I removed the overlays from the tours, now they are working again for the time being, but with a worse graphics.

For this, this and this mention on Wikidata today I did not receive a notification. Maybe I missed some more mentions. The last successful notification I received is from 15:40, 9 October 2017 (UTC)

I created five new lists:
Wikidata:Tools/Edit items
Wikidata:Tools/Query data
Wikidata:Tools/Enhance user interface
Wikidata:Tools/Visualize data
Wikidata:Tools/For programmers

The only data my bot throws away are descriptions if the merge is done with QuickStatements or the client sitelink widget, see table below.

The length limit does also affect the migration of constraints from property talk pages to statements on properties. ISBN-13 has a format expression which is 481 characters long and therefore can't be added to the property page.

fixed

see moveClaim.js by @matej_suchanek.

My bot is checking recentchanges for edit summaries containing \/\* wbmergeitems-to:0\|\|(Q[0-9]+) \*\/
For each match, it checks if a redirect was created. If not, the bot does the following:

1. it merges the item again with ignoreconflicts=descriptions
2. it clears the item
3. it creates the redirect.

This is done with the same procedure since 2015 and it has not led to any user complaints. Based on this experience, I think it is safe to call by default after a merge the clear and createredirect functions.

duplicate of T16439

The part about entering the globe field is covered by T56097.

A solution for [[https://www.wikidata.org/wiki/Property:P213|P213]],[[https://www.wikidata.org/wiki/Property:P919|P919]] and possibly others would be adding capturing groups to the regular expression and using these capturing groups to create the URL.

This patch causes that PropertyPage.exists() throws an error.

This happens because of a bug in the authorityControl gadget. However, special handling of IMSLP IDs by the gadget is no longer needed, therefore we can simply remove the special handling to fix the link display. https://www.wikidata.org/w/index.php?title=MediaWiki%3AGadget-AuthorityControl.js&type=revision&diff=405961503&oldid=388594916

In T144687#2608519, @hoo wrote:

Currently we consider an Item a "valid" (countable) article if it has either at least one statement or at least one sitelink (as far as I remember).