Jane023 added a comment.
In T258776#6334164 <https://phabricator.wikimedia.org/T258776#6334164>,
@Jarekt wrote:
> I think Wikidata and SDC has an issue with representation of Wikimedia
pages. Sometimes thy are stored as URLs (see Property:P1957
<https://www.wikid
Jane023 added a comment.
In T235420#6078389 <https://phabricator.wikimedia.org/T235420#6078389>,
@DemonDays64 wrote:
> Any progress on this?
>
> Being able to add Wikidata sitelinks to redirects is important in my
opinion because of things like French Wikipedia ha
Jane023 added a comment.
I agree with earlier posts and would say I have zero motivation to contribute
to SDoC until such a query service is available to me, because working on
paintings I find Wikidata workflows much easier to monitor and lacking that for
Commons I can't make any overviews
Jane023 added a comment.
This is apparently a sub-task of T54564
<https://phabricator.wikimedia.org/T54564>, which is the Bonnie and Clyde
problem (see on Wikidata Help:Handling_sitelinks_overlapping_multiple_items). I
think the best solution is to radically delete all redirect
Jane023 added a comment.
No to the OAuth issue - OAuth is visibly logged in. I cannot even paste into
the window to get the import loaded so I am unable to answer the rest of your
question. All edits (before and after with old interface) are correctly logged
under my userid.
TASK DETAIL
Jane023 added a comment.
I noticed this late last night and had been using QS all day. I just switched
to the old interface and that is still working. So something must have happened
around dinner time? Like 6-9 PM GMT or Western European time.
TASK DETAIL
https
Jane023 added a comment.
Magnus told me about this tool, which gathers painting items with same
creator in "painted by" description. You need to fill in the Q number of the
artist which you can create or lookup.
https://tools.wmflabs.org/mix-n-match/painters.php
TASK DETA
Jane023 closed this task as "Resolved".
Jane023 claimed this task.
Jane023 added a comment.
This is not a bug. Everything is working as expected. The problem was
entirely on the user side in their interpretation of the error message, which
was entirely correct.
TASK DETA
Jane023 added a comment.
No I have not explained it well then. Try to think of it in terms of postal
districts or voting districts. As a town grows, generally neighboring villages
are annexed, but they do not lose their postal codes or voting district names.
This is just as true
Jane023 added a comment.
Yes sorry if the statements seem so ambiguous, this is just one of many cases
where such things occur. One is a historic city and one is a current city. The
problem probably arises because there is so little left of the original
historic center in today's city, due
Jane023 added a comment.
The message you received was correct. There is a help page for this:
https://www.wikidata.org/wiki/Help:Merge
TASK DETAIL
https://phabricator.wikimedia.org/T226238
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Jane023
Jane023 added a comment.
I am back and after checking, happy to report I was right. One is the town,
and the other is the municipality. They are not the same and should not be
merged.
TASK DETAIL
https://phabricator.wikimedia.org/T226238
EMAIL PREFERENCES
https
Jane023 added a comment.
No for me it doesn't show up. Also the query should return 74 items and it only returns 69 for me. The same problem exists for the same Q when you run the query against Q58590616 instead: this time I get 78 results when it should be 80. So there seem to be a small group
Jane023 added a comment.
This is my query which does not return all items:
SELECT ?item ?catcode WHERE {
?item p:P528 [ pq:P972 wd:Q53207781 ; ps:P528 ?catcode].
}
Example missing item: Q31158443. This item was created using the duplicate item gadget, so not sure if that matters.TASK
Jane023 added a comment.
This appears to be the same issue I reported here. Hope this is just a question of waiting a few days for servers to be in sync, and not months for a bug fix.TASK DETAILhttps://phabricator.wikimedia.org/T207675EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings
Jane023 added a comment.
The 6 test items uploaded well but these were the first 6 ids (1,2,3,4,5,6) and after upload these were added in decimal format with ".0" after the number. Open refine is great when it works as expected... Meanwhile multichill has also added some images to exis
Jane023 added a comment.
In T89600#4018766, @Jarekt wrote:
What other Wikidata properties we should harvest?
It would be nice if items listed under "Owned by" on Wikidata could be stuffed into "| object history =" in the artwork template on Commons.TASK DETAILhttps://phabr
Jane023 added a comment.
I have come to understand (mostly through trial and error, and then asking around) that to reduce the time on the query you need to start with the thing that has the least number of items in the group you want to query. As these "sub groups" get bigger and bigg
Jane023 added a comment.
Hmm that is nice, that doesn't seem to work too well for Rembrandt. I guess his paintings have traveled too far over time. I like the plot of the places of residence, but it would be nice to have them plotted with lines in order of residence. We have lots of people
Jane023 added a comment.
Yes that map for Leiden looks interesting on a per-location basis. I really like the idea of connecting the dots however. It also gives people some motivation to type in the places artists lived and worked, rather than just stopping at the birth and death places.TASK
Jane023 created this task.Jane023 added projects: Wikidata, Maps (Maps-data).Herald added a subscriber: Aklapper.
TASK DESCRIPTIONWith all of the various ways to use maps these days, we should be able to do this too. See for example this feature enabled for people on the RKD website (e.g
Jane023 added a comment.
I think the problem that forms the basis of this task is not very well formulated. It might be worthwhile to convert this task into one of documentation on Wikidata and if people still feel strongly after understanding all the issues, then maybe link it to some strategy
Jane023 added a comment.
Yes I would drop the word "bias" then. It is about identifying and
measuring gaps, no? There should be a link somewhere to the bias side of
things (not sure where that is - diversity?)TASK DETAILhttps://phabricator.wikimedia.org/T127475EMAIL PREFER
Jane023 added a comment.
Shouldn't his be split into biases and content gaps? The first is hard to measure (involves the community of editors personally - e.g. who they are groupwise, such as gender, nationality, age, education etc) and the second is a bit easier (coverage of geo-locations, topics
Jane023 added a comment.
In https://phabricator.wikimedia.org/T54564#2286466, @ChristianKl wrote:
> If Wikidata wants to draw new contributors then it would be valuable if you
don't need to use complicated hacks to create sitelinks to redirects.
Generally new contributors to W
Jane023 added a comment.
I have tried but have not been able to replicate this issue yet. It does
appear to update the target item in real time or very close to real time.
TASK DETAIL
https://phabricator.wikimedia.org/T133719
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings
Jane023 added a comment.
Interesting! Is there any way to alert when the user hits save that the
wikidata item is or could not be updated? I mean I have in the past saved to a
userpage as a test, so obviously linking that to the wikidata item would not
work (I just saved under another name
Jane023 added a subscriber: Jane023.
TASK DETAIL
https://phabricator.wikimedia.org/T95682
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: hoo, Jane023
Cc: Jane023, gerritbot, Bugreporter, Tobi_WMDE_SW, Smalyshev, Laddo, MGChecker,
Sannita, Micru
Jane023 added a subscriber: Jane023.
TASK DETAIL
https://phabricator.wikimedia.org/T120778
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Jane023
Cc: Jane023, Lydia_Pintscher, daniel, Aklapper, StudiesWorld, DannyH,
Wikidata-bugs, aude
Jane023 added a subscriber: Jane023.
TASK DETAIL
https://phabricator.wikimedia.org/T99899
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Jane023
Cc: Jane023, Spage, Smalyshev, Bene, Ricordisamoa, Addshore, jeremyb, Aklapper,
daniel, Wikidata-bugs
Jane023 added a subscriber: Jane023.
TASK DETAIL
https://phabricator.wikimedia.org/T76827
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Jane023
Cc: Jane023, Steinsplitter, Ricordisamoa, brion, MaxSem, Addshore,
JanZerebecki, aude, MZMcBride
Jane023 added a comment.
Getting back to the original comment, I think we should be thinking in terms of
creating an export data package that can be used by any Wikimedia project or
any external party. Think infobox for Wikipedia and image template for
Commons. Each Wikimedia project should
Jane023 added a comment.
There have been several RfC's on Wikidata for this issue, most recently this
one (closed with no consensus):
https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Sitelinks_with_fragments
TASK DETAIL
https://phabricator.wikimedia.org/T54564
EMAIL PREFERENCES
Jane023 added a comment.
No, the answer is not to create a sitelink to a redirect. The answer is to
overhaul the Kilowatt hour article and split it into an article mostly
about the history of the measurement and link it to a new short article on
Watt hour, which today is but a lowly redirect
Jane023 added a comment.
Try to think of Wikidata in the same context as Wikimedia Commons. A few
would probably agree with you that eventually every image will have its own
Wikipedia article. I am not one of those people.
TASK DETAIL
https://phabricator.wikimedia.org/T54564
EMAIL
Jane023 added a comment.
I see that I was unclear in my wording. I wasn't asking about a Wikipedia merge
action but a Wikidata merge action. In your examples you are only referring to
Wikipedia. The example you give on the football player probably comes closest
to the person-duo problem, so I
Jane023 added a comment.
If you don't want items to be merged, you need the separate items to be
able to have sitelinks.
No, it is fine for items to have zero sitelinks. Not everything in the
Wikiverse revolves around Wikipedia
TASK DETAIL
https://phabricator.wikimedia.org/T54564
EMAIL
Jane023 added a comment.
We are already doing more than imagining GLAM applied to Wikidata, we are
applying GLAM datasets to Wikidata at Wikidata:WikiProject sum of all paintings
https://www.wikidata.org/wiki/Wikidata:WikiProject_sum_of_all_paintings
We not only have Maarten who is busy adding
Jane023 added a subscriber: Jane023.
TASK DETAIL
https://phabricator.wikimedia.org/T101950
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Qgil, Jane023
Cc: Jane023, I9606, Scott_WUaS, Abraham, Susannaanas, Multichill, Smalyshev,
Romaine, Wittylama
Jane023 added a comment.
What you are describing is a Wikipedia merge action, which is indeed common on
Wikipedia for various reasons. However, that does not indicate to me that there
is any need for a corresponding merge action on Wikidata, as such a merge does
not mean the Wikidata items
Jane023 added a comment.
What you are describing is a Wikipedia merge action, which is indeed common on
Wikipedia for various reasons. However, that does not indicate to me that there
is any need for a corresponding merge action on Wikidata, as such a merge does
not mean the Wikidata items
Jane023 added a subscriber: Jane023.
Jane023 added a comment.
I am against implementing this so-called fix,because it would undermine what
Wikidata is all about. Wikidata is meant to interlink same or highly similar
concepts in different languages. As a language wiki expands, in the normal
42 matches
Mail list logo
