agray added a subscriber: agray.
agray added a comment.
This is a good idea, I think.
It might be best to simply prevent merging any two items which link to each
other (A>B, B>A, or A<>B), in the same way that a merge is prevented if it
would lead to a duplicate sitelink.
If it's
agray created this task.
agray added a subscriber: agray.
agray added a project: Wikidata.
Herald added subscribers: StudiesWorld, Aklapper.
TASK DESCRIPTION
The edit link for labels/descriptions is displayed on top of the
description. This is not normally a problem, but if the description
agray edited the task description.
agray set Security to None.
TASK DETAIL
https://phabricator.wikimedia.org/T117864
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: agray
Cc: Aklapper, StudiesWorld, agray, Wikidata-bugs, aude, Mbch331
agray created this task.
agray added a subscriber: agray.
agray added a project: Wikidata.
Herald added subscribers: StudiesWorld, Aklapper.
TASK DESCRIPTION
When a property has 'item' datatype, this can be entered either by directly
typing the item ID, eg `Q123`, or by typing the item label
agray added a comment.See also https://phabricator.wikimedia.org/T117763 - suggesting allowing (Q123) as a valid entry as well as Q123.TASK DETAILhttps://phabricator.wikimedia.org/T122019EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: agrayCc: agray, Movses
agray created this task.
Herald added subscribers: Zppix, Aklapper.
TASK DESCRIPTION
When viewing Special:ListProperties (language set to Gaelic
<https://www.wikidata.org/wiki/Special:ListProperties?uselang=gd>), all
properties shown are rendered in the same way and labelled as the
agray edited the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T135045
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: agray
Cc: Aklapper, Zppix, agray, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331
agray changed the title from "Correct language fallback rendering on
Special:Allpages" to "Correct language fallback rendering on
Special:ListProperties".
TASK DETAIL
https://phabricator.wikimedia.org/T135045
EMAIL PREFERENCES
https://phabricator.wikimedi
agray created this task.
Herald added subscribers: Zppix, Aklapper.
TASK DESCRIPTION
When adding a property to Wikidata items using the web interface, it is easy
to unintentionally create a duplicate property entry - particularly on large
items, where you may not notice that the property
agray created this task.
Herald added subscribers: Zppix, Aklapper.
TASK DESCRIPTION
At the moment, Wikidata has four/five preferences options for automatically
adding pages to the watchlist: "Add pages and files I edit to my watchlist";
"Add pages and files I move to my w
agray added a comment.
Here's one I did this evening:
https://www.wikidata.org/w/index.php?title=Q26204001="">
I created this using the QuickStatements tool, using the AGbot account, and then made several more edits to it with the same tool in the same session. This account has
agray added a comment.
Checked using a different tool (edit made through PetScan/WIDAR) - account has "Add pages and files I edit to my watchlist", "Add pages and files I move to my watchlist", and "Add pages I create and files I upload to my watchlist" ticke
agray created this task.agray added a project: Wikidata-Query-Service.Herald added a subscriber: Aklapper.Herald added projects: Wikidata, Discovery.
TASK DESCRIPTIONAt the moment, WDQS supports only one type of map, a standard OSM-based Mercator projection which runs from (approximately) 85N
agray added a comment.
This all sounds great until...
...because slashes are a hint at the American format MM/DD/, while all other punctuation characters typically hint at DD.MM..
...which sounds completely weird to me. In fact, I raised the possibility and dismissed it as obviously
agray created this task.agray added a project: Wikidata.Herald added a subscriber: Aklapper.
TASK DESCRIPTIONWhen information is entered into a property field with 'time' datatype (eg start time, P580), the system makes an attempt to parse what's been entered and convert it into a coherent
agray added a comment.
[Apologies - forgot to ever put in a response to this. Thanks for looking into it.]
I agree that 07/09/2017 is always a bit ambiguous and we can never reliably say what the user means. But I guess what's confusing me here is that 07-09-2017 or 07 09 2017 are also a bit
agray created this task.agray added a project: Wikidata.Herald added a subscriber: Aklapper.
TASK DESCRIPTIONGregorian calendar dates between 1582 and c. 1920 in Wikidata have a "change to Julian" link in the drop-down menu.
If I open one of these dates to change it to Julian, and cli
agray updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTIONGregorian calendar dates between 1582 and c. 19201930 in Wikidata have a "change to Julian" link in the drop-down menuTASK DETAILhttps://phabricator.wikimedia.org/T178255EMAIL PREFER
agray added a comment.
We might need to sort on more qualifiers than just P585. This is becoming an issue for P39 claims, where it's not unknown for someone to have 10-20 claims or even more if they had a long career (especially in politics where they might hold a lot of different official posts
agray added a comment.
One other sorting method that might be useful - P1545 qualifiers on P2093 claims (used for huge numbers of scholarly articles) or P735 claims (starting to become common for people with first and middle names). It looks like we will need a general solution for sorting
agray created this task.agray added a project: Wikidata Query UI.Restricted Application added a subscriber: Aklapper.Restricted Application added a project: Wikidata.
TASK DESCRIPTIONA table query result in Wikidata which returns more than 200 results (by default) is shown over multiple pages
agray renamed this task from "Wikidata Query Service embedded results page " to "Wikidata Query Service embedded results interface makes it difficult to access multiple pages of results".
TASK DETAILhttps://phabricator.wikimedia.org/T201094EMAIL PREFERENCEShttps://phabr
agray added a comment.
To follow up on @Jheald and @Lydia_Pintscher's comments here - for a lot of use-cases, I agree that a lag measured in a few hours isn't much of a problem, because the underlying data is fairly static. Most property values don't change minute-to-minute or even month-to-month
agray added a comment.
Can confirm that my experience (probably on ~20 Sept if that helps narrow it down; Firefox 62 under Ubuntu) was as Magnus describes it. It happened on one or two pages; I haven't had it happen since and assumed it was some weird local browser issue so didn't file a bug
agray added a comment.
Can confirm I've just had it on https://www.wikidata.org/wiki/Q29201051 as well.
I get it on other items in the same browser session (https://www.wikidata.org/wiki/Q211775; https://www.wikidata.org/wiki/Q904305) but not others (https://www.wikidata.org/wiki/Q287; https
agray added a comment.
@GoranSMilovanovic - I can confirm that the numbers on the tables seem a bit
off for some other properties. I've been looking at P1614
<https://phabricator.wikimedia.org/P1614> (History of Parliament), which is
complete and fairly stable. It currenty has 214
agray added a comment.
In T204440#5112446 <https://phabricator.wikimedia.org/T204440#5112446>,
@GoranSMilovanovic wrote:
> @agray
>
> > For VIAF (P214) the dashboard reports 440 items, against a SPARQL total
of 2807.
>
> - For VIAF P214, the dashboard re
agray added a comment.
@GoranSMilovanovic thanks! Looking back at my tests for P.1614, these are the
new numbers in the overlap data column (tables view, left hand column). They're
a lot higher, but I think they're still incomplete.
- P.1614/P.214 overlap - reported as 1654, should
agray added a comment.
@GoranSMilovanovic oh hurrah - glad you've traced the problem! Those numbers
for P1614 <https://phabricator.wikimedia.org/P1614> sound pretty much what I'd
expect given it's data from February, so it looks like it's solved. Thanks for
this, the dashboard look
agray created this task.
agray added a project: Wikidata-Query-Service.
Restricted Application added a subscriber: Aklapper.
Restricted Application added a project: Wikidata.
TASK DESCRIPTION
At the moment, the query service can give results as XML, JSON, TSV, CSV, and
RDF if a service sends
agray updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T232665
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: agray
Cc: pdehaye, Aklapper, agray, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86,
Lucas_Werkmeister_WMDE
agray added a comment.
In T215073#5456845 <https://phabricator.wikimedia.org/T215073#5456845>,
@Tagishsimon wrote:
>
> So, per the main proposition: a one-size-fits-all tiling solution is
suboptimal. It would be infinitely preferable to be able to extend th
agray added a comment.
I'm still getting this with "normal" properties (ie not just
`wikibase:quantityUnit`) on https://www.wikidata.org/wiki/Q334443 - it's
showing up as a duplicate in P39 <https://phabricator.wikimedia.org/P39>-based
searches which return the item, and
agray created this task.
agray added a project: Wikidata-Query-Service.
Restricted Application added a subscriber: Aklapper.
Restricted Application added a project: Wikidata.
TASK DESCRIPTION
The query service is giving different notation formats for numbers in TSVs
depending on the method
agray updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T249728
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: agray
Cc: Aklapper, agray, darthmon_wmde, Nandana, Lahi, Gq86, GoranSMilovanovic,
QZanden, LawExplorer, _jensen
agray created this task.
agray added a project: Wikidata.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
If a user tries to add a sitelink to an item which already exists, they get
this message:
> Could not save due to an error.
> The save has
agray added a comment.
As an interim workaround, I've put together a quick-and-dirty script to
slowly do a rolling purge of items using pywikibot. It identifies all items
that have not been edited since before the formatter URL was changed, generates
a list, and works through them
agray added a comment.
Looks like the test queries above are all returning the "normal" expected
results now - hopefully this means the reload has fixed things!
(@Mmarx's one with P495 <https://phabricator.wikimedia.org/P495> returns some
P-values, but they all seem legi
agray added a comment.
In T112081#6404998 <https://phabricator.wikimedia.org/T112081#6404998>,
@valerio.bozzolan wrote:
>
> Is this scheduled?
>
> For example we noticed that `P6288` should be purged.
It's not scheduled in any way - just a
agray added a comment.
A way to get access in WDQS to "original calendar" values would really be
helpful.
At the moment, we're in an odd situation where the dates in WDQS are
technically correct by ISO 8601 (I think), but most users interested in looking
at historic
agray added a comment.
I believe the code governing this is in
https://gerrit.wikimedia.org/r/plugins/gitiles/wikidata/query/gui/+/refs/heads/master/wikibase/queryService/ui/resultBrowser/ImageResultBrowser.js#245
(lines 245-7)
So we could change
url = this._getThumbnail
agray added a comment.
It has occurred to me today that this problem is (in some ways) a blessing in
disguise - it helps mitigate against the effects of vandalism by deleting or
changing a formatter URL.
If we do manage to solve this eg by having a server-side script purge items
after
agray added a comment.
I flagged up the other case mentioned. As an example of the issue -
At the time of writing, https://w.wiki/kxw returns four items, three edited
on 12 October and one on 27 October. All have removing Q99671172 (which is now
no longer linked from any items
agray added a comment.
I am still seeing a handful of inconsistencies stemming from the same period
of edits. For example this edit
<https://www.wikidata.org/w/index.php?title=Q5540133=1327746719=1327746707>
to Q5540133 on 23 December has not propagated to all databases, and so
agray added a comment.
In T285076#7163976 <https://phabricator.wikimedia.org/T285076#7163976>,
@Amire80 wrote:
> Langco//**M**//.
>
> Looks good to me, I guess, although I am curious about the source. Do these
appear in a dictionary?
Very few are in the shorte
agray added a comment.
@Delane13 It is possible to do this conversion within the SPARQL service -
approximately, you would want something like this query
<https://query.wikidata.org/#%23%20query%20to%20demonstrate%20ways%20to%20manipulate%20dates%0A%23%20find%20rawdate%2C%20precision
agray added a comment.
After looking at this afresh I think part of my first suggestion is moot: it
is possible to get an indication of the calendar model in use for a given
statement by using **wikibase:timeCalendarModel** (see eg https://w.wiki/5MPi
for the "point in time" of t
agray added a comment.
This would be useful for copy-pasting, but how would it interact with people
manually typing IDs?
It's not very common, but especially for very short/frequently used IDs (and
definitely for properties), it can be easier to type eg "Q27" than "Repub
agray added a comment.
Thanks so much for dealing with this so promptly! Will the update script need
to be run on Commons as well?
TASK DETAIL
https://phabricator.wikimedia.org/T315693
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Ladsgroup
agray added a comment.
Maybe something like:
> In recent months, there have been inaccurate numbers shown for various
[[Special:Statistics]] at Commons, Wikidata, and English Wikipedia. This has
now been fixed.
It was //fixed// this week, but presumably the problem dates b
agray added a comment.
There are two issues that I noted during the page-count problems the other
month, and neither are a blocker here but if we're changing content namespaces
it might be a good time to think about them -
- Special:Statistics and the main page display a count of pages
agray added a comment.
@Tagishsimon I *think* that is a subtly different problem, connected to the
deletion not being done quickly enough for the moved sitelink to catch up?
There's an existing bug logged for it as T233435
<https://phabricator.wikimedia.org/T233435> (also t
agray added a comment.
@dcausse For the sample here (enwiki FAs) it affects ~0.1% over the course of
a year, and presumably older ones are being swept up by the reloads. I think
that's reasonable enough to file as "a rare problem" if the alternative would
cause performa
agray created this task.
agray added a project: Wikidata-Query-Service.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
There are currently five items (wd:Q108861497 wd:Q113867071 wd:Q6390796
wd:Q17129703 wd:Q112621799; query <https://w.wiki/5yRA>) which s
54 matches
Mail list logo
