In T244529#5860081, @Tarrow wrote:

We're rolling back to wmf.16 on all wikis. We hope this will resolve the issues but of course some bad data may now be cached. We'll look at this again on Monday.

This is also showing up on Commons in the infobox and other templates that use Wikidata, see:
https://commons.wikimedia.org/wiki/Template_talk:Wikidata_Infobox#Family_relations_show_up_as_Q_values
https://commons.wikimedia.org/wiki/Commons:Village_pump#Familytree_template_and_Wikidata_info
+1 to 'unbreak now' please!

If you search for ticket numbers (e.g., 'T243479'), then you can reach the corresponding ticket - but no free text searching it seems.

OK, I've tentatively closed this, if you start getting the notifications again then please reopen it!

OK, two test edits:

In T243130#5818856, @Dudley_Miles wrote:

They are all Commons categories so far I remember. Examples are Category:Sole Common Pond, Category:Westfield Farm Chalk Bank, Category:Easton Farm Meadow, Category:Boxford Water Meadows.

@Dudley_Miles Could you give some examples of articles/categories where you received notifications from me, please? One thought is that I am using a Python script to add these links rather than the editing interface, and in some cases I add both the enwp and commons link simultaneously to a new item linking the two. Perhaps that somehow means that the option blocks one notification but somehow lets the other through.

This is now live in the main version of the infobox.

Thank you, @Addshore, for investigating this issue!

Thanks! There's a possible new case from the last few days at https://commons.wikimedia.org/wiki/Category:Henrik_Harpestrengs_Vej / https://www.wikidata.org/wiki/Q81792970

If null edits work, and this isn't a problem where new cases will be created in the future, then I could run a bot through them to make null edits - is there is a list of all affected pages?

Added to {{Wikidata Infobox/sandbox}} for testing.

I haven't seen any live examples of this recently, so I'm marking this as resolved.

In T235811#5657800, @egardner wrote:

The widgets in the WikibaseMediaInfo extension use templates and render() methods to ensure that the visible UI remains in sync with the structured data as it changes. Existing DOM elements are often thrown out and re-rendered from scratch to ensure consistency. Our introduction of this workflow into the Captions widget is probably what initially broke this gadget.

I'll have a look around for some current examples, but I haven't seen any for the last week, so this may well have been solved with the deadlocks issue. Although T233520 (page_props missing links) is definitely still happening, and may be related to clearing out any old cases here as well.

This hack generally doesn't seem to work now. I think something has changed in the SDC code that means that the hook no longer works. I'm not sure if that can be fixed within the gadget, or if it requires a tweak to the SDC HTML. Perhaps @Jdforrester-WMF or @Abit could have a look?

I can currently normally find live examples of this by looking through the English Wikipedia for commons category links missing from Wikidata - so if you need live examples when debugging this, let me know and I can provide some.

In T231621#5473600, @Lokal_Profil wrote:

In T231621#5473597, @gerritbot wrote:

Change 534972 had a related patch set uploaded (by Lokal Profil; owner: Lokal Profil):
[labs/tools/heritage@master] [WIP]Add br_pt as a sparql harvest
https://gerrit.wikimedia.org/r/534972

The blocker for getting this set up with the above is that I don't know enough sparql to select the ?item qid as ?id (i.e. a string/literal)

Sure, what country tracking category would you like it to add? I've done a demo at https://commons.wikimedia.org/wiki/File:At_Paraty,_Brazil_2017_107.jpg that currently puts it into "Category:Monuments by ID in Brazil", but any other format of "Category:prefix <country> postfix" is straightforward to implement. (But different prefixes/postfixes for different countries would be messy.)

Thanks! The convention follows https://commons.wikimedia.org/wiki/Category:Cultural_heritage_monuments_with_known_IDs, in this case https://commons.wikimedia.org/wiki/Category:Cultural_heritage_monuments_in_Brazil_with_known_IDs

In T231621#5455033, @JeanFred wrote:

3. by the nature of point 1 there will be no tracking category for images with ids for the dataset.

The MonumentID could figure it out based on the Wikidata invoke and add the relevant country-based category.

I'll ping @Mike_Peel here, as he is the creator of the MonumentID template on Commons. What do you think, Mike?

The session was unfortunately not recorded, but you can see the output of the demo:
https://en.wikipedia.org/wiki/User:Mike_Peel/infobox
https://en.wikipedia.org/wiki/User:Mike_Peel/sandbox99
(look at the history).

In T145279#5384625, @kaldari wrote:

Following from the general switch to using the sitelinks for Commons over the last year...

@Mike_Peel - Could you explain this sentence? What is the "general switch"?

I've been re-running my bot code today, and it's found a few more from 2017 on tgwiki, but nothing more recent. So I'm closing this for now. Note that there are still cases on enwp, but I'm not sure that will be resolved in this ticket anyway.

https://wikimania.wikimedia.org/wiki/2019:Languages/Wikidata_Infoboxes has also been accepted.

We've just come across this issue on Commons, see discussion at https://commons.wikimedia.org/w/index.php?title=Template_talk:Wikidata_Infobox&oldid=357725187#following_redirects_on_wikidata . I've increased it to high priority.

I'll be around. I think there's some overlap between this and T221394 though - and also https://wikimania.wikimedia.org/wiki/2019:Languages/Wikidata_Infoboxes - that we should figure out so there's not too much repetition!

Note that the original issue I filed this ticket for now seems to have been fixed - the quarry query has run successfully for the last few days.

Is there an opportunity for a retrospective here to figure out why it wasn't included in the original plan? It seems quite a basic component for SDC, and it's been requested for quite a while (or at least, I remember asking about it at last year's Wikimania!).

My suggestion would be to simply mirror the functions that are currently available for Q-items - either by duplicating the code that does that and changing "Q" to "L", or better, generalizing it so that it works for all of Wikibase's namespaces (P/Q/L/M/...). Then it can be built upon on-wiki as needed (e.g., through Module:WikidataIB). That would also help structured data on commons, and future projects using wikibase.

Hi all. I'll be at the hackathon, and would be happy to talk about / work on wikidata generated infoboxes there (amongst other things, e.g., using pywikibot).

In T222965#5178214, @Multichill wrote:

.wb-otherproject-commons {display:none;} hides it in css, see https://commons.wikimedia.org/wiki/User:Multichill/vector.css . That's a decent work around.

I think this is basically solved now, barring cleanup? Following from the general switch to using the sitelinks for Commons over the last year, the interwiki links now appear on Commons through the sitelinks in most cases. Where the category is linked to a category item, {{Interwiki from Wikidata}} and {{Wikidata Infobox}} sort out the relevant links. So I think this task can now be closed?

There's plenty left to do, but it's not being tracked here, so I've marked this as resolved now. Thanks!

It still seems to be possible to add a sitelink through pywikibot (e.g., https://www.wikidata.org/w/index.php?title=Q8416977&diff=prev&oldid=895355247 ) - so this seems to be an interface issue.

Same problem here. At https://www.wikidata.org/wiki/Q62554440 - try to add a sitelink, and you're not given the boxes to add the link to https://en.wikipedia.org/wiki/Battle_Creek_City_Hall.

Aah, I found the problem. I was using the LoginManager class in pywikibot to log in, but I actually needed to use the site class to log in. So, it now works! This edit was by the code that's now on bitbucket:
https://commons.wikimedia.org/w/index.php?title=File:Sala_S%C3%A3o_Paulo_2018_07.jpg&diff=prev&oldid=337738484

That's great, thank you!

I'm closing this as there's a different way of doing it, so this isn't needed. Thanks for looking at it!

Ah, I had a typo in my test code - the javascript at https://commons.wikimedia.org/w/index.php?title=User%3AMike_Peel%2Fcommon.js&type=revision&diff=334439260&oldid=324345310 does actually work! So maybe that's the best way forward for now.

I think you just answered your own question. The display:none approach is already in use, but mw-collapsed would be better so it's not completely disabled, and as things stand that requires a html id. I'm happy to see the problem solved a different way, this is just how I know the problem can be solved.

Yes, I was meaning an actual HTML id. That way, users can add additional css classes to the ID using their user javascript page, e.g., $( "#captions" ).addClass( "mw-collapsed" ); - or better yet, provide some other way to let users auto-collapse the caption box, like a gadget or by having it as a beta feature. From my experience with the wikidata infobox on commons, this is a good way of keeping those that don't want to see the extra box happy.

In T184933#4821845, @hoo wrote:

In T184933#4819706, @Lea_Lacroix_WMDE wrote:

@hoo Another question was also raised: is it possible to adapt the scale of the map (=zoom level) depending on what it is about?
(see discussion here)

I looked at this briefly and it would be hard to integrate with how the maps are currently generated. Also on commons units are not currently respected when evaluating this… that's something we would need to get right.
We could adapt the zoom based on precision, though (see T211676).

This is very nice! I'm not sure if I should raise these points here or in a new bug, but I have three suggestions (based on deploying kartographer on Commons):

I posted this in the 2019 wishlist, but withdrew it as I realised that it's not actually possible to edit the maps at the poles on OSM as they use the same projection - so this probably needs OSM to fix things first. Not sure if it's possible to mark another organisation as the blocker for this issue!

@Lydia_Pintscher @Addshore Matěj Suchánek wrote a Quarry query that looks for bad sitelinks, see:
https://www.wikidata.org/wiki/Wikidata:Request_a_query#Identifying_interwiki_links_that_no_longer_exist

In T201371#4597175, @Addshore wrote:

Hi @Mike_Peel how are the edits going?

The bot was approved, and is running. Edits are being logged at https://www.wikidata.org/wiki/User:Mike_Peel/tgwiki_sitelink_fixes .

That's fine, but it's still a bug that needs to be fixed at some point. So I've re-opened it with a low priority for now.

I've submitted a bot request:
https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bot/Pi_bot_9
It will take a few days to be approved, so I'll probably run this over the weekend. The bot will be quite general, so should this happen again in the future (with tgwiki or elsewhere) then I'll also be able to fix those too.

The query approach didn't find any, but looking through VASHGIRD's contributions on wikidata found several that were deleted from tgwiki and the sitelink automatically removed from wikidata, e.g. at Q9729338 and Q13201301 . So this must have been a temporary glitch. I'll work on removing the broken links, then this can be closed.

In T201371#4518906, @Greta_Doci_WMDE wrote:

I would suggest to do a test, ask someone from the administrators to create a page, link it to wikidata, and then delete it. To see if this was a specific issue at that time. And then you can remove the entries and we close the ticket here.

It ultimately turned out that "nosave=1" when passed to the coord template disabled the coordinates in the API. Removing that parameter should now have resolved this.

Should I leave the examples live, or can I remove them from the wikidata entries?

There are quite a few examples now on my user subpage, but from what I can see they are all deletions by VASHGIRD on 17-18 October 2017. Perhaps there was a specific issue at that time?

In T199892#4460347, @eranroz wrote:

• Example 2: (@Mike_Peel may know better how it works in enwiki - so please correct me if I'm wrong) In some communities such as enwiki there is/was no clear consensus to autofill parameters from Wikidata by default, and sometimes the prefered approach is two equivalent templates ([[Template:Infobox person]] and [[Template:Infobox person/Wikidata]]) and the user can decide to explicitly use /wikidata. In that case it may make sense to have wikidata mapping even in the non wikidata version, so user can verify the data is compatible before switching to /wikidata version.

Please be careful with cases like https://en.wikipedia.org/wiki/Template:Infobox_telescope - where the infobox fetches the information from Wikidata in a formatted way, rather than asking users to start putting things like {{#property:P569}} everywhere. It's very valuable to do the matching of wikidata properties against the fields using templatedata, so that we don't have to have manual tables that describe the info; and for users to be able to edit the Wikidata information directly or provide a local text override, but copying info from Wikidata or adding in extra tags to fetch Wikidata info should be avoided.

This is also relevant for Wikimedia Commons, where we now have infoboxes in categories that can take up quite a few screen-pages on mobile, e.g. try https://commons.m.wikimedia.org/wiki/Category:Barack_Obama . See T199931 for details.

In T199931#4436581, @Papuass wrote:

Do we wish to collapse or hide it? There is CSS class "nomobile".

In T198716#4426379, @Salgo60 wrote:

Isnt it adding a Twitter Cards what should be done?

I've mentioned this at https://commons.wikimedia.org/wiki/Commons:Village_pump#Enable_PageImages_on_Commons_categories to make sure that this is OK with the wider commons community.

Any chance you could regenerate all of the plots from the 2-month set of results, but using the 6-month dataset, please?

When I've seen this happening, I've just assumed it's due to large job queues, and that the update will happen eventually. Does changing the page on Wikidata not add the refresh tasks to the job queue?

In T184000#3990055, @Mike_Peel wrote:

Will it be possible to access/display the descriptions in the text of other articles (e.g., list articles, or ideally even on Commons/other projects), or will this be write-only from the perspective of editing?

In T184000#3988364, @Alsee wrote:

However the seesaw/swing example still proves the fundamental point. Wikidata descriptions are descriptions of Wikidata items, for Wikidata purposes. Trying to put a Czech article-description in the Wikidata-description would be flat-out wrong. And using a Wikidata description as the Czech article description is going to be wrong.
Wikidata descriptions commonly have a passable resemblance to article descriptions, and some clients may sloppily or carelessly use them for that purpose, but Wikidata descriptions are not article descriptions. They never were.