User Details
- User Since
- Apr 16 2018, 12:29 AM (225 w, 1 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Tagishsimon [ Global Accounts ]
May 1 2022
Bouzinac can minimise the minimap using the arrow at its bottom-right, after which it does not interfere with scrolling the layer list.
Nov 16 2021
It's always a huge red flag, when assessing a proposed change, to read a user story which is self-evidently detached from reality. This and other klaxons of doom are found in this proposal.
Nov 11 2021
@Legoktm might you be able to provide any details of that evidence?
Nov 10 2021
@Legoktm is there any evidence that the current link shortener has been abused in the way you fear a link shortener capable of shortening longer URIs might be? b/c right now, a couple of years after this change request was made, we still have no effective way of communicating lengthy SPARQL reports on, for instance, social media, or in the Wikidata weekly summary - which for obvious reasons would prefer not to be bloated by 5k SPARQL report URIs where 19 char URIs would suffice.
Aug 18 2021
@TheDJ noted. It's up to the WMF to decide whether they're going to support users and improve the product in obvious ways such as the above; or whether they're just going to sit back and count their astronomically huge pile of money. It's really only all the users and all the editors who are currently being ill-served. it doesn't take much imagnation to see that wikimedia would be better served by appropriately detailed maps, and so the question is, why is this a backwater for WMF? I live in hope that WMF, replete with a plurality of communications managers, gets back to us on this one.
Can you describe any use cases, @Pikne, which are frustrated by the normal convention of showing progressively increasing amounts of information as the resolution of the map increases?
If I'm going to validate scheduled monuments in Scotland (8,086 items), I need to be able to see archaeological sites.
I'll end, for now, with: as I've spend many hundreds of hours over several years curating the geocoded items for a country - Scotland - WMF might want to reciprocate by providing maps fit for purpose. The current map set is demonstrably not fit. Boundaries, buildings, landuse, peaks, please.
Are my Scottish items with coordinates in the correct P131 area?
Bergen, zoom 11. Wikidata has 1,000s of hills & summits. use case: show them so that we can check whether WD coordinates point to the peaks.
Victoria Falls. The railway is one of the defining features, as it goes over the gorge from Zambia to Zimbabwe. Users can almost see it on the WMF map, if they know what they're looking for.
Downtown Lusaka, Zambia
Edinburgh: Look - no castle! Mostly, no buildings. Unrecognisable. Entirely useless for my listed buildings use case.
Noting T288897 ... if WMF maps are to be sorted out, it is reasonable to consider whether it is now time to learn from map specialists such as OSM/ACME and implement the easily available and obviously useful map detail which they supply.
Aug 17 2021
in fact, it's more than a refresh issue; WMF choose to use maptiles which filter out most of the useful information. Compare WMF and OSM at the same resolution for Haroldswick, in the Shetlands:
Aug 16 2021
With any luck these illustrate the issue, although clicking on https://maps.wikimedia.org/#9/45.7004/10.5139 and zooming around shows the problem.
Jun 30 2021
Jun 29 2021
It's been noted on WD:talk that there's no consensus to do this, and so a technical implementation is premature.
May 9 2021
Apr 20 2021
link this to https://phabricator.wikimedia.org/T185476 ... both presentation and specification of the title within the SPARQL could be improved. Arguably per T185476 and its children, there is considerable room for improvement of, clarity of configuration of, and documentation of charts. Right now it's a dark art.
Mar 25 2021
I hope 'push[ing] it up the priority list' is not the case. The RfC would need to attract consensus, or even interest, first. What appear to be OWNer-ish facets of signed statements seem antithetical to WD's openness, at least, to me.
Nov 25 2020
This issue is still occurring. We still get different answers depending on which report server we hit. That is clearly suboptimal. Could we please have an update on action being taken, and/or the timetable for proposed action, presuming that action will be taken. @Lydia_Pintscher
Oct 20 2020
It may or may be not useful to note that Quickstatements, when used in (server-side) batch mode to create new items, creates duplicates at the rate of about 10% of the items created. QS run locally from a browser does not exhibit the problem.
Jun 18 2020
Magnus was running 2 quickstatement batches at the time he got the above. My experience of this issue is that it'll sometimes happen when I have a QS or two running, but has never happened absent a QS.
May 11 2020
Mar 3 2020
Jan 30 2020
UI which has the capacity to mangle input and demands that the user must do something beyond their simple input of the date, is unambiguously, categorically and unimpeachably broken. It should be considered as such.
We could maybe have a preference, such that the user can specify whether they want date parsing to be based on an assumption of MM/DD/YYYY or DD/MM/YYYY. Stop guessing. Ask the users.
Jan 5 2020
Is there a problem with increasing the size limit. It /seems/ like a very easy quickwin. What's the story?
Jan 4 2020
Wikidata currently gets ~660k edits per day.
Nov 21 2019
Notable that WDQS lag seems to be paying not a blind bit of notice to this change :(
Nov 7 2019
Per Laske, SPARQL for this issue in Germany [https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team#Surplus_of_coordinates_-_T198078]
Nov 6 2019
Ditto http://www.wikidata.org/entity/Q17567523 ... there are probably others.
@Smalyshev Please check out the single coords property at https://www.wikidata.org/wiki/Q6522893#P625 versus the two rows returned by this query, suggestive of 'hidden' triples lurking still.
Oct 23 2019
And note Ethan's assertion: The scheme for Geonames URIs requires a trailing forward slash.
Oct 19 2019
Fix by all means, but I note "It is an error for aggregates to project variables with a name already used in other aggregate projections, or in the WHERE clause." https://www.w3.org/TR/sparql11-query/#aggregateExample
Sep 16 2019
Tested - works for me in situation in which it previously didn't work.
Sep 13 2019
Sep 1 2019
Can I gently detach this issue, somewhat, from disputed territory. The current situation is that maps served by Wikipedias & (my key use) Wikidata WDQS use "OSM Bright for Mapbox Studio" tiles ( https://foundation.wikimedia.org/wiki/Maps_Terms_of_Use#Where_does_the_map_data_come_from? )
Jul 20 2019
Worth noting that user:Twofivesixbot
Jun 16 2019
May 30 2019
@FriedhelmW ... purge != clear cache. https://www.refreshyourcache.com/en/home/
May 21 2019
Seems more likely it's a data input issue than a query issue @matej_suchanek, given that WDQS doesn't exhibit the same sort of error for analogous wdtn:, such as wdtn:P244 (Library of Congress authority ID) - see for instance https://w.wiki/48X
de link is showing. local caching issue for @FriedhelmW ?
May 17 2019
May 15 2019
+1 for this. Further example of a long SPARQL report is at https://twitter.com/Tagishsimon/status/1128769104674996234 fwiw
May 2 2019
And the clear risk with this issue is that if one enters a search term that should get a match ... for instance - Judith Schwarz - and places a reliance on the dropdown, then seeing no dropdown, as if the search term did not match anything, will, for instance, lead to the creation of duplicates.
Apr 30 2019
Apr 29 2019
Apr 27 2019
Apr 5 2019
Feb 26 2019
That's not a fix, so much as a helpful workaround.
closed as duplicate of or subsumed within T214984
@Aklapper thanks - I've moved the contents to that ticket & will close this.
Let me add content from << T217103: Extension:Kartographer producing "Couldn't parse JSON" errors when SPARQL includes queryhints >> since this seems a part of the issue raised here and may provide an additional failure-mode example:
Feb 25 2019
Feb 16 2019
No, I'll not be doing that, any more than you just have. Whilst a serious outage is being treated merely as a curiosity, it is well worth reminding WMF employees that outages like this are far from acceptable.
Day 2 of no Quickstatements, no Listeria, no ETA for a resumption of service ... no comment from WMF on why what is a critical service - if we're taking this whole wikidata business at all seriously - is fritzed.
Feb 1 2019
And to prove the curate's egg, http://petscan.wmflabs.org/?psid=7075446&al_commands=P31%3AQ5%0AP21%3AQ6581072 when run again, 502d.
Mixed results. The following three worked like a charm:
Sorry to burden you with this. As a user 502s are v.frustrating, but I can also imagine it's v.frustrating for you to be asked to debug when you could be making snowmen instead.
502 examples in the last couple of minutes:
Thanks Magnus. I run those two daily; get perhaps 20% 502s, without an obvious pattern. There are others (e.g. listed on https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Women_in_Red/Metrics/Wikidata ) which more reliably 502
How about we work out what's going on BEFORE we peremptorally close this issue. "As far as I know" does not cut it.
Ideally Cloud-Services will liaise with @Magnus either to bottom out & solve the issue; or else to provide an explanation for the 502 issue which we can use to console ourselves each time it happens.
Jan 31 2019
So far as I know, the fault is not with Petscan, but with the WMF infrastructure on which it operates. Please do not be so hasty to dismiss problems like this.
Jan 26 2019
Jan 21 2019
Jan 16 2019
Nov 20 2018
@Jdlrobson Do we need to provide a description? Would not <meta name="twitter:card" content="title"/> provide our extant <title></title> contents to the twitter card. (I really don't know, but from first principles that seems to be what specifying content="title" would be likely to do.)
Is it really blocked, or is the best driving out the good? Would not something as simple as <meta name="twitter:card" content="title"/> be a massive improvement on the current highly suboptimal rendering - example: https://twitter.com/Tagishsimon/status/1064868689995071488
Nov 8 2018
thx
Nov 7 2018
Nov 4 2018
Thx @LucasWerkmeister. All makes sense now :)
Oct 27 2018
My regex is not great, but \?(\S*?)[\s\)}\.]
@Jonas - is there not a pattern that we could use instead of /^[\w\d]*/ ... we have a questionmark followed by not white space followed by a space or by ) or } or .