Wikidata weekly summary #342
This Month in GLAM: November 2018
|
Infobox observatory
Hi there. I saw that you altered this template back in August per https://phabricator.wikimedia.org/T169935, only to have it reverted two hours later. Should the phabricator ticket be reopened, or is there a better place to discuss this? Or has this already been discussed somewhere and dismissed as unfixable?
At the time of writing, all articles using infobox observatory are again omitting coordinates in response to a simplest-possible API query. (I suspect the same must be happening for infobox bridge, but I can't find any bridge articles that don't also specify coordinates in the article itself.) --Lord Belbury (talk) 10:56, 18 December 2018 (UTC)
- Lord Belbury, It's because coordinates don't have to be in the infobox. Some articles have coordinates defined outside of the infobox and the infobox cannot know about this. It will thus fallback to wikidata coordinates and potentially add two sets of coordinates. The 'nosave' hides this clash in coordinates from the error detection (as it hides it from the api). So the problem exists in both versions, it's just in one version it fills an error category and this seems to piss off certain editors and in the other the same editors remain blissfully unaware of the problem. A way around this is to move any {{coord}} that are currently outside an infobox into the coordinates param of the infobox. Alternatively, you can remove the 'title' display setting by default for Wikidata included coordinates and make that something that has to be explicitly defined. —TheDJ (talk • contribs) 12:30, 18 December 2018 (UTC)
- TheDJ: Thanks for the explanation, but I'm still struggling to understand what's happening here. Is there some nuance in how Wikidata-coordinate infoboxes are rendering "title" coordinates, compared to how {{coord|display=title}} would? Documentation at Template:Coord#Caveats implies that if a coordinate is shown in the title, the API can also see it - but the coordinates put there by Wikidata infoboxes aren't (with nosave=1) visible to the API. Is that all "nosave" is doing? (I can't see that it's documented in the {{coord}} template.) --Lord Belbury (talk) 14:52, 18 December 2018 (UTC)
- Lord Belbury, so by default the Module:Coordinates which backs the en.wp implementation of coordinates, executes the #coordinates parser function. This parser function is responsible for adding coordinates to the database and linking them to that page. It does that for ALL coordinates, title or inline. However display=title coordinates are marked as 'primary' and thus indicating that the coordinates belong to the primary topic of that page. Inline coordinates are only added as 'secondary' coordinates, requiring a different api query to retrieve them. nosave omits running the #coordinates function and as a side effect thus not only avoids coordinates from showing up as primary coordinates, they don't even show up as secondary coordinates either. It also disables the error check this parser function normally runs (multiple primary markers is an error situation), which fills Category:Pages_with_malformed_coordinate_tags, which the reverter apparently keeps a close eye on. It however doesn't prevent these pages from having two overlapping sets of title coordinates shown at the top right (which is handled by Module:Coordinates and not the parser function), which... these 900 or so pages that the reverter complained about probably still have, which is the other side effect of having two display=title coordinates on a single page. But what you choose to ignore doesn't exist.... let's all just complain about wikidata.. sigh. —TheDJ (talk • contribs) 16:18, 18 December 2018 (UTC)
- TheDJ: Thanks for the explanation, but I'm still struggling to understand what's happening here. Is there some nuance in how Wikidata-coordinate infoboxes are rendering "title" coordinates, compared to how {{coord|display=title}} would? Documentation at Template:Coord#Caveats implies that if a coordinate is shown in the title, the API can also see it - but the coordinates put there by Wikidata infoboxes aren't (with nosave=1) visible to the API. Is that all "nosave" is doing? (I can't see that it's documented in the {{coord}} template.) --Lord Belbury (talk) 14:52, 18 December 2018 (UTC)
- I have some half-written bot code to move coordinates from the article text into the appropriate infobox parameter, but it still needs work (and then bot approval). Hopefully that would then mean that the alteration to the template can be restored without causing a conflict. I moved onto other things, though, I'll see if I can go back to this. Thanks. Mike Peel (talk) 17:33, 18 December 2018 (UTC)
- Thanks, that sounds like a good path forwards. Good luck with it. --Lord Belbury (talk) 10:07, 19 December 2018 (UTC)
Wikidata weekly summary #343
ygm
JarrahTree 07:04, 23 December 2018 (UTC)
- @JarrahTree: Replied. Thanks. Mike Peel (talk) 07:27, 23 December 2018 (UTC)
- Thank you for speedy response - have a very good christmas and new year ! JarrahTree 07:44, 23 December 2018 (UTC)
The Signpost: 24 December 2018
- From the editors: Where to draw the line in reporting?
- News and notes: Some wishes do come true
- In the media: Political hijinks
- Discussion report: A new record low for RfA
- WikiProject report: Articlegenesis
- Arbitration report: Year ends with one active case
- Traffic report: Queen dethroned by U.S. presidents
- Gallery: Sun and Moon, water and stone
- Blog: News from the WMF
- Humour: I believe in Bigfoot
- Essay: Requests for medication
- From the archives: Compromised admin accounts – again
Wikidata weekly summary #344
Facto Post – Issue 19 – 27 December 2018
Facto Post – Issue 19 – 27 December 2018
![]() The Editor is Charles Matthews, for ContentMine. Please leave feedback for him, on his User talk page.
To subscribe to Facto Post go to Wikipedia:Facto Post mailing list. For the ways to unsubscribe, see the footer.
Zotero is free software for reference management by the Center for History and New Media: see Wikipedia:Citing sources with Zotero. It is also an active user community, and has broad-based language support. ![]() Besides the handiness of Zotero's warehousing of personal citation collections, the Zotero translator underlies the citoid service, at work behind the VisualEditor. Metadata from Wikidata can be imported into Zotero; and in the other direction the zotkat tool from the University of Mannheim allows Zotero bibliographies to be exported to Wikidata, by item creation. With an extra feature to add statements, that route could lead to much development of the focus list (P5008) tagging on Wikidata, by WikiProjects. There is also a large-scale encyclopedic dimension here. The construction of Zotero translators is one facet of Web scraping that has a strong community and open source basis. In that it resembles the less formal mix'n'match import community, and growing networks around other approaches that can integrate datasets into Wikidata, such as the use of OpenRefine. Looking ahead, the thirtieth birthday of the World Wide Web falls in 2019, and yet the ambition to make webpages routinely readable by machines can still seem an ever-retreating mirage. Wikidata should not only be helping Wikimedia integrate its projects, an ongoing process represented by Structured Data on Commons and lexemes. It should also be acting as a catalyst to bring scraping in from the cold, with institutional strengths as well as resourceful code.
Diversitech, the latest ContentMine grant application to the Wikimedia Foundation, is in its community review stage until January 2.
If you wish to receive no further issues of Facto Post, please remove your name from our mailing list. Alternatively, to opt out of all massmessage mailings, you may add Category:Wikipedians who opt out of message delivery to your user talk page.
Newsletter delivered by MediaWiki message delivery |
MediaWiki message delivery (talk) 19:08, 27 December 2018 (UTC)
Disambiguation link notification for December 29
An automated process has detected that when you recently edited Monte Tamaro (ship), you added a link pointing to the disambiguation page Santos (check to confirm | fix with Dab solver).
(Opt-out instructions.) --DPL bot (talk) 09:13, 29 December 2018 (UTC)
Administrators' newsletter – January 2019
News and updates for administrators from the past month (December 2018).
|
![]()
|
- There are a number of new or changed speedy deletion criteria, each previously part of WP:CSD#G6:
- G14 (new): Disambiguation pages that disambiguate only zero or one existing pages are now covered under the new G14 criterion (discussion). This is {{db-disambig}}; the text is unchanged and candidates may be found in Category:Candidates for speedy deletion as unnecessary disambiguation pages.
- R4 (new): Redirects in the file namespace (and no file links) that have the same name as a file or redirect at Commons are now covered under the new R4 criterion (discussion). This is {{db-redircom}}; the text is unchanged.
- G13 (expanded): Userspace drafts containing only the default Article Wizard text are now covered under G13 along with other drafts (discussion). Such blank drafts are now eligible after six months rather than one year, and taggers continue to use {{db-blankdraft}}.
- The Wikimedia Foundation now requires all interface administrators to enable two-factor authentication.
- Members of the Bot Approvals Group (BAG) are now subject to an activity requirement. After two years without any bot-related activity (e.g. operating a bot, posting on a bot-related talk page), BAG members will be retired from BAG following a one-week notice.
- Starting on December 13, the Wikimedia Foundation security team implemented new password policy and requirements. Privileged accounts (administrators, bureaucrats, checkusers, oversighters, interface administrators, bots, edit filter managers/helpers, template editors, et al.) must have a password at least 10 characters in length. All accounts must have a password:
- At least 8 characters in length
- Not in the 100,000 most popular passwords (defined by the Password Blacklist library)
- Different from their username
- User accounts not meeting these requirements will be prompted to update their password accordingly. More information is available on MediaWiki.org.
- Blocked administrators may now block the administrator that blocked them. This was done to mitigate the possibility that a compromised administrator account would block all other active administrators, complementing the removal of the ability to unblock oneself outside of self-imposed blocks. A request for comment is currently in progress to determine whether the blocking policy should be updated regarding this change.
- {{Copyvio-revdel}} now has a link to open the history with the RevDel checkboxes already filled in.
- Following the 2018 Arbitration Committee elections, the following editors have been appointed to the Arbitration Committee: AGK, Courcelles, GorillaWarfare, Joe Roe, Mkdw, SilkTork.
- Accounts continue to be compromised on a regular basis. Evidence shows this is entirely due to the accounts having the same password that was used on another website that suffered a data breach. If you have ever used your current password on any other website, you should change it immediately.
- Around 22% of admins have enabled two-factor authentication, up from 20% in June 2018. If you haven't already enabled it, please consider doing so. Regardless of whether you use 2FA, please practice appropriate account security by ensuring your password is secure and unique to Wikimedia.
Wikidata weekly summary #345
Location map issue
Hello Mike. Can I ask for your help with regards to this issue, please? It seems like the cause is {{Infobox power station}}'s location map not using the local data when provided, but I cant seem to figure out that part of the code unfortunately. Happy New Year! Rehman 08:12, 1 January 2019 (UTC)
- Happy New Year, Rehman! Mike, it looks like Jonesey95 has fixed the problem. Cheers --RexxS (talk) 16:24, 1 January 2019 (UTC)
![⚠](https://upload.wikimedia.org/wikipedia/commons/thumb/3/34/Ambox_warning_blue.svg/35px-Ambox_warning_blue.svg.png)
Thanks for uploading File:Trudi Canavan The Novice cover.jpg. The image description page currently specifies that the image is non-free and may only be used on Wikipedia under a claim of fair use. However, the image is currently not used in any articles on Wikipedia. If the image was previously in an article, please go to the article and see why it was removed. You may add it back if you think that that will be useful. However, please note that images for which a replacement could be created are not acceptable for use on Wikipedia (see our policy for non-free media).
Note that any non-free images not used in any articles will be deleted after seven days, as described in section F5 of the criteria for speedy deletion. Thank you. --B-bot (talk) 18:50, 3 January 2019 (UTC)
Hello MIke,
I noticed for Category:1966_in_the_United_States_by_state that the link on the side menu 'Wikimedia Commons' links to Commons:Category:1966 in the United States while the wikidata item corresponding to Category:1966 in the United States by state wikidata:Q8154351 has no prpoerty P373 and the link to Other sites indicates commons:Category:1966 in the United States by state.
Id onot understand this behaviour normally I would expect to see the link to 'Wikimedia Commons' in the Side menu to either point to the link to the Commons link indicated in wikidata or to the category indicated as P373 property on Wikidata.
Is there something I do not catch. thanks for your Feedback --Robby (talk) 22:48, 5 January 2019 (UTC)
- @Robby: It's just a caching error, as I recently fixed that sitelink, see the page history and Category:1966 in the United States by state or territory (Q8154351). Adding "?action=purge" to the end of the enwp URL seems to have cleared it. Thanks. Mike Peel (talk) 07:30, 6 January 2019 (UTC)
- Thanks for the information. Is there any place to get more information on how long it can take for the cached information to be updated. I did till now never find this information and many times solved it with making a blind edit (in order to get maintenance categories up to date as some times even after days the corresponding maintenance category was no t yet updated). Thanks Robby (talk) 14:53, 6 January 2019 (UTC)
- @Robby: My best estimate is around two weeks or a month here, but it depends on how well trafficked / edited the page or category is. Enwp seems to have much longer caching than Commons does. Null edits seem to be the way to go if needed, and I can do those by bot if needed, but that will increase the server loads so I try to do that as little as I can. Thanks. Mike Peel (talk) 14:56, 6 January 2019 (UTC)
- Thanks for the information. Is there any place to get more information on how long it can take for the cached information to be updated. I did till now never find this information and many times solved it with making a blind edit (in order to get maintenance categories up to date as some times even after days the corresponding maintenance category was no t yet updated). Thanks Robby (talk) 14:53, 6 January 2019 (UTC)
Wikidata weekly summary #346
This Month in GLAM: December 2018
|