Jump to content

User talk:Mike Peel/Archive 41

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 35Archive 39Archive 40Archive 41Archive 42Archive 43Archive 45

Wikidata weekly summary #342

This Month in GLAM: November 2018





Headlines
  • Albania report: Wiki Photo Walk Albania 2018; Wiki Loves Monuments Albania
  • Armenia report: Singing Wikipedia; Photographs by Vahan Kochar
  • Brazil report: Diverse milestones for the Brazilian community
  • Denmark report: Intercontinental digitisation efforts
  • Estonia report: Making contacts both internationally and in Estonia
  • Finland report: Art and edit-a-thons
  • France report: Bibliothèque publique d’information; 3D museum collections on Wikimedia Commons
  • Indonesia report: Conserving and digitizing texts in West Sumatra
  • Macedonia report: Wiki Training at National and University Library "St. Clement of Ohrid"
  • New Zealand report: Equity, Wikidata, and the New York Times
  • Norway report: Collaboration with The National Archives of Norway
  • Philippines report: Wiki Loves Art
  • Poland report: Archival image uploads, student collaborations and international projects
  • Serbia report: Photo finish of the WIR's
  • Sweden report: The Swedish Performing Arts Agency; Library data starts to take shape; Learning Wikipedia at the Archives; Wikimedia Commons Data Roundtripping
  • UK report: Sum of All Astrolabes
  • USA report: Wikidata Workshop at Pratt School of Information; Wikidata Presentation for the New York Technical Services Librarians; Wikipedia Asian Month; Cleveland Park Wikipedia Edit-a-thon; Historic Ivy Hill Cemetery Workshop
  • Wikipedia Library report: Books & Bytes–Issue 31, October–November 2018
  • WMF GLAM report: Welcoming Satdeep Gill; Structured Data on Commons; WikiCite
  • Calendar: December's GLAM events
Read this edition in fullSingle-page

To assist with preparing the newsletter, please visit the newsroom. Past editions may be viewed here.

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 (talkcontribs) 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 (talkcontribs) 16:18, 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

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.

Learning from Zotero

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.

Zotero logo

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.

Zotero demo video

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.

Links

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)

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).

Guideline and policy news

  1. 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.
  2. 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.
  3. 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}}.

Technical news

  • 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:
  1. At least 8 characters in length
  2. Not in the 100,000 most popular passwords (defined by the Password Blacklist library)
  3. 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.

Arbitration

Miscellaneous

  • 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)
Happy New Year, RexxS! :-) Thank you Jonesey95! Best wishes, Rehman 03:13, 3 January 2019 (UTC)

Orphaned non-free image File:Trudi Canavan The Novice cover.jpg

⚠

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)
Possibly related bugs: T132467 and T157670. – Jonesey95 (talk) 23:16, 6 January 2019 (UTC)

Wikidata weekly summary #346

This Month in GLAM: December 2018





Headlines
  • Armenia report: Cooperation with Yerevan Drama Theatre Named After Hrachia Ghaplanian; Singing Wikipedia (continuation); Photographs by Vahan Kochar (continuation)
  • Australia report: 2019 Australia's Year of the Public Domain
  • Belgium report: Writing weeks German-speaking Community; End of year drink; Wiki Loves Heritage photo contest
  • Brazil report: Google Art and GLAM initiatives in Brazil
  • India report: Collaboration with RJVD Municipal Public Library
  • Italy report: Challenges and alliances with libraries, WLM and more
  • Macedonia report: Exhibition:"Poland through photographs" & Wikipedia lectures with children in social risk
  • Malaysia report: Technology Talk and Update on Wikipedia @ National Library of Malaysia
  • Portugal report: Glam Days '18 at the National Library of Portugal
  • Sweden report: Hats 🎩🧢👒🎓
  • UK report: Oxford
  • USA report: Holiday gatherings and visit to Internet Archive
  • Wikidata report: Wikidata reports
  • WMF GLAM report: Structured Data on Wikimedia Commons: pilot projects and multilingual captions
  • Calendar: January's GLAM events
Read this edition in fullSingle-page

To assist with preparing the newsletter, please visit the newsroom. Past editions may be viewed here.