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.

Ah, sorry, that wasn't clear! Although I suspect this might be better to solve in the general case, than to create a special case for one situation. Maybe that's better linked with things like foot/inches than datestamps, though.

Don't forget to include the time zone!

I've added a proposal to fix this to the 2017 community wish list - see https://meta.wikimedia.org/wiki/2017_Community_Wishlist_Survey/Miscellaneous/Stop_ifexist_checks_from_appearing_in_Special:WhatLinksHere . Comments/feedback/description edits are welcome there!

Here's what I said in the task that's been merged into this one:

I often use Commonist to bulk upload photos to Commons using my normal editing account. The new files are automatically added to my watchlist, and they are also added to a category I have on my watchlist.
Mostly this displays fine in my watchlist, but every so often there is a glitch in the order that the edits appear, and at the same time one of the category additions gets marked as a bot edit, even though it isn't. See the attached screenshot as an example.
This has been happening for a while (I've been spotting it happening for the last few months), it's not a new issue, and it doesn't break anything. But it is an oddity.

In T177707#3673562, @Bawolff wrote:

RelatedChanges, RecentChanges, and watchlist are all the same behind the scenes. They all have the same feasibility concerns.

Sure, I thought that this might help reduce the amount of duplicate info stored, since presumably you'd just store the change with the linked item and then be able to pick up that linked item change through RelatedChanges. Apologies if I'm missing the problem.

"Open question: Where should the cut-off initially be?" - the problem I have here is that it's particularly useful to see changes to highly-used pages, as it's those same pages that need to be watched closer to make sure that vandalism is quickly reverted. E.g. if a country name is vandalised, that needs to be caught quickly. If that's not feasible, then I'm not sure I see the benefit of having a middle-region, perhaps it should only appear for the directly linked page... Or maybe it should show in RelatedChanges rather than RecentChanges.

I filed a new report about this thinking it was a recent problem - I didn't realise it dated back to 2007! The new report I posted was:

For cases where this has caused issues, please see:

• https://en.wikipedia.org/wiki/Wikipedia:Templates_for_discussion/Log/2017_September_15#Queries
  • and report at https://en.wikipedia.org/w/index.php?title=Template_talk:Cite_Q&oldid=802807663#Issue_with_erroneous_links_in_WhatLinksHere_for_author_and_editor_names_.28work-around_in_place.29
• https://en.wikipedia.org/w/index.php?title=User_talk:Mike_Peel&oldid=802860361#Template:infobox_journal

Just to mention that I'm experiencing this issue using Firefox 55.0.3 on Mac OS.

Thanks @Yurik. Tracking at T175102.

Trying to import https://pt.wikipedia.org/wiki/Predefini%C3%A7%C3%A3o:Mapframe/Wikidata onto enwp (at https://en.wikipedia.org/wiki/User:Mike_Peel/Mapframe - doesn't currently seem to work - test by trying to add {{User:Mike Peel/Mapframe}} to https://en.wikipedia.org/wiki/Lovell_Telescope and you just see the code not the map.

This happens occasionally to me as well, but with "pt-BR". Sometimes it seems like it's due to the page not finishing loading before I try to save the edit, but I'm not sure about that.

The copy of the code that the bot runs has also now been updated.

After a hard refresh to clear my cache it does indeed now work. Thanks!

It's up to you if you want to take over maintenance and running of the code yourself (it's simple code with minimal requirements), or I can update the code when the new permissions sheet is available.