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.

It seems odd that, in order to get the data (the Q-numbers), you have to strip formatting from the values (as opposed to adding preferred formatting to data). Being able to simply get a list of Q-ids should be one of the simplest Wikidata queries possible...

The 'diff' and 'hist' links aren't working correctly either - they point towards the page on enwp, which doesn't show any changes, rather than to a page on Wikidata.

I wonder if this might be better done through a property that allows qualifiers, so that each redirect can be marked up with the rationale for why it is a redirect (including common typos, foreign language versions, etc.). Although quite how that could interact with MediaWiki/Wikibase, I'm not sure!

In T102417#3098196, @Nemo_bis wrote:

Having a separate box for Commons would make it a lot clearer that commons links can be added in the same way that other sister sites can be.

Showing a difference helps conveying that there is no difference? Quite an oxymoron.

Probably should have posted this here rather than there:

@Lydia_Pintscher Looking through this after our discussion today, @bzimport's comment above about the needs for astronomy looks good. RA, dec and epoch, e.g. see the values in the infobox at https://en.wikipedia.org/wiki/SN_1987A . Support for other astronomical coordinate systems (such as Galactic coordinates) would also be good, but that can be done later (and possibly by auto-converting them) - for now, just supporting equatorial coordinates would be incredibly useful for the work I'm doing with astronomical infoboxes.

Thank you!

In T150210#3060615, @Lokal_Profil wrote:

Per T150210#2954454 you will need to raise this on the tasks for making a new release. At this point 2.0r5 is so far behind master that it might not be possible to reliably backport individual patches.

Please consider fixing this in 2.0rc5/the pip install version. I just came across this, and spent the time to debug my code to make sure that wasn't the problem, tracked down the problematic value on a Wikidata entry, wrote a test script that demonstrates the issue, tested it on several computers, and came here to submit the bug - only to then find this thread. If the pip version was up-to-date, none of that would have been necessary. :-(

Thanks Daniel - I'm looking forward to that version being released!

There was also the important point that the assumed uncertainty shouldn't be shown (or stored), and should only be used internally to calculate conversions, unless the uncertainty has been properly set by a user. Not sure that was captured here in this ticket, but maybe it's in another one?

In T104735#2449250, @Bawolff wrote:

In T104735#2448220, @Mike_Peel wrote:

Thanks @Bawolff! wmfusercontent.org now works as expected. However, accessing https://phab.wmfusercontent.org/ gives the error message:

To be clear, i did not fix, i just noticed it was fixed.

Thanks @Bawolff! wmfusercontent.org now works as expected. However, accessing https://phab.wmfusercontent.org/ gives the error message: