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
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 15 2020
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?
Jan 1 2020
Added to {{Wikidata Infobox/sandbox}} for testing.
Dec 14 2019
Nov 29 2019
I haven't seen any live examples of this recently, so I'm marking this as resolved.
Nov 12 2019
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.
Nov 11 2019
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?
Nov 6 2019
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.
Oct 14 2019
Sep 22 2019
Sep 14 2019
Sep 9 2019
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 harvestThe 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)
Aug 31 2019
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:
- 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?
Aug 20 2019
Aug 15 2019
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).
Aug 1 2019
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"?
Jul 28 2019
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.
Jul 19 2019
https://wikimania.wikimedia.org/wiki/2019:Languages/Wikidata_Infoboxes has also been accepted.
Jul 10 2019
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.
Jul 9 2019
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!
Jul 1 2019
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.
Jun 27 2019
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!).
Jun 18 2019
Jun 4 2019
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.
May 30 2019
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).
May 14 2019
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.
May 10 2019
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?
Apr 14 2019
There's plenty left to do, but it's not being tracked here, so I've marked this as resolved now. Thanks!
Mar 27 2019
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.
Feb 4 2019
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
Jan 30 2019
Jan 15 2019
That's great, thank you!
Jan 12 2019
I'm closing this as there's a different way of doing it, so this isn't needed. Thanks for looking at it!
Jan 11 2019
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.
Dec 13 2018
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).
Dec 12 2018
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):
Nov 6 2018
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!
Sep 29 2018
Sep 24 2018
@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
Sep 23 2018
Sep 19 2018
In T201371#4597175, @Addshore wrote:Hi @Mike_Peel how are the edits going?
Sep 1 2018
The bot was approved, and is running. Edits are being logged at https://www.wikidata.org/wiki/User:Mike_Peel/tgwiki_sitelink_fixes .
Aug 24 2018
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.
Aug 22 2018
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.
Aug 21 2018
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.
Aug 17 2018
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?
Aug 7 2018
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?
Aug 6 2018
Jul 31 2018
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.
Jul 22 2018
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.
Jul 20 2018
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.
Jul 19 2018
In T199931#4436581, @Papuass wrote:Do we wish to collapse or hide it? There is CSS class "nomobile".
Jul 18 2018
Jul 16 2018
In T198716#4426379, @Salgo60 wrote:Isnt it adding a Twitter Cards what should be done?
Jul 12 2018
Jul 4 2018
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.
Jul 3 2018
Apr 19 2018
Any chance you could regenerate all of the plots from the 2-month set of results, but using the 6-month dataset, please?
Apr 17 2018
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?
Mar 28 2018
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?
Feb 21 2018
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.
Jan 30 2018
Jan 29 2018
Jan 28 2018
Dec 7 2017
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.
Dec 6 2017
Don't forget to include the time zone!
Nov 18 2017
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!
Oct 19 2017
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.
Oct 14 2017
Oct 10 2017
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.
Sep 28 2017
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: