Pintoch added a comment.
Quick update on this: undoing edit batches on Wikidata via the current
EditGroups has been broken for about two months now and the few hours I have
spent trying to fix it have not been sufficient so far.
On the surface it seems related to the instability of the
Pintoch created this task.
Pintoch added projects: Wikidata, Wikidata Lexicographical data.
TASK DESCRIPTION
**Steps to replicate the issue** (include links if applicable):
- Go to https://www.wikidata.org/wiki/Lexeme:L1259271
**What happens?**:
- A qualifier is rendered as &quo
Pintoch added a comment.
Ok, I think I still don't understand it fully, but I trust you do and won't
stand in the way ^^
TASK DETAIL
https://phabricator.wikimedia.org/T266344
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Pintoch
Pintoch added a comment.
> For OpenRefine(and other tools) the benefit would be that RDF ontologies
can be extended very easily so that tools can define their own (namespaced)
properties.
Where would those namespaced properties be published?
- If it is in the document served
Pintoch added a comment.
Thanks for reviving this thread I had forgotten about ^^
I don't think I fully understand your vision here, because it's not clear to
me what problem we would solve by using an ontology in this case.
To me, the main problem is that the information
Pintoch added a comment.
Yes, if it was unclear from my comments I can try to clarify again here. From
an API user perspective my preferences are (from most preferred to least
preferred):
1. `wikibase-entityid` datavalue type, for consistency with the targeted user
experience
Pintoch added a comment.
@Addshore wrote a blog post summarizing the options around this problem and I
think it's a very worthy read:
https://addshore.com/2023/07/wikibase-and-reconciliation/
TASK DETAIL
https://phabricator.wikimedia.org/T244847
EMAIL PREFERENCES
Pintoch added a comment.
If it's not too difficult, it would be helpful to have that behavior in
`list=recentchanges` too, typically for tools which do recent changes polling.
(EditGroups sadly uses the EventStreams
<https://wikitech.wikimedia.org/wiki/Event_Platform/EventStreams&
Pintoch added a comment.
Thank you both, this should simplify the EditGroups tool quite a bit! Here is
an example of page where I had to render entity links manually, with some
Javascript post-processing code:
https://editgroups.toolforge.org/b/CB/3683873dde8d/. (I guess I will keep
this
Pintoch added a comment.
Thanks for the heads up, I have opened an issue about it on OpenRefine's
side: https://github.com/OpenRefine/OpenRefine/issues/5658
TASK DETAIL
https://phabricator.wikimedia.org/T330859
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/
Pintoch added a comment.
Agreed, I would say PAWS replaces this task.
TASK DETAIL
https://phabricator.wikimedia.org/T194767
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Pintoch
Cc: Spinster, Nattes, LucasWerkmeister, yuvipanda, CennoxX
Pintoch added subscribers: Tarrow, VladimirAlexiev.
Pintoch added a comment.
Here is the current status of this issue:
The team at TIB (headed by @Loz.ross) is now maintaining the current wrapper
and has contributed improvements to deploy it on other Wikibase instances:
https
Pintoch added a comment.
A feature request came in: handling changes of username on the wiki
<https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&diff=1787084712&oldid=1787082920>.
I suspect this is a feature that would likely come "for free" in any
Pintoch added subscribers: SebastianHellmann, Pintoch.
Pintoch added a comment.
This bug was mentioned today at LSWT'22 <https://dataweek.de/lswt2022/> by
@SebastianHellmann as a blocker for integrating Wikidata in linked data
applications.
Fetching a URI with content negotia
Pintoch updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T244847
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Pintoch
Cc: GFontenelle_WMF, jdtoy, SandraF_WMF, JeanFred, Fuzheado, Eugene233,
PabloCastellano, Loz.ross
Pintoch added a comment.
@Spinster I'd rather keep this open since this is a problem that is likely to
be relevant to other tools and still has not been solved as far as I can tell.
It seems similar to T282732 <https://phabricator.wikimedia.org/T282732> which
is current appare
Pintoch added a comment.
If someone takes the initiative to run a bot to propagate Wikidata redirects
in Commons, they might be interested in integrating that bot with the
EditGroups instance for Commons (https://editgroups-commons.toolforge.org/,
that I just deployed) so that the effect of
Pintoch added a comment.
Thanks a lot @Mvolz! The new endpoint running at
https://wikidata.reconci.link/ is much more stable but I assume that it is even
harder for you to rely on something that is outside the WMF ecosystem (compared
to a toolforge project).
TASK DETAIL
https
Pintoch removed a project: Wikidata-Query-Service.
TASK DETAIL
https://phabricator.wikimedia.org/T266212
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Pintoch
Cc: Pintoch, Aklapper, VladimirAlexiev, Akuckartz, darthmon_wmde, Nandana,
Lahi, Gq86
Pintoch created this task.
Pintoch added a project: Wikidata.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
In March 2020, the entity Black Girl (Q70778234)
<https://www.wikidata.org/w/index.php?title=Q70778234&redirect=no> was
redirected to Black Girl
Pintoch added a comment.
It does use tools-redis indeed!
TASK DETAIL
https://phabricator.wikimedia.org/T257405
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Pintoch
Cc: Bstorm, Thadguidry, Lydia_Pintscher, Nemo_bis, Nintendofan885, bd808
Pintoch added a comment.
Yesterday the `https://wdreconcile.toolforge.org/` service returned 504
errors for all URLs (after a waiting time - they did not appear "cached" as in
this ticket). Restarting the service seems to temporarily mitigate the issue,
so it's probably a di
Pintoch added a comment.
Oh I see, sorry for the misunderstanding!
Concerning the items and properties in this Wikibase instance, I think that
looks good. I see you have added items and properties for the constraint system
- that's great! But it is not clear to me if the qu
Pintoch added a comment.
It looks great! Here are a few comments:
- I assume the constraint ids don't appear there because the quality
constraints extension is not installed on this wiki, but would appear otherwise?
- In the manifests that we use, we have currently added a `m
Pintoch added a comment.
@Samantha_Alipio_WMDE that sounds perfect!
TASK DETAIL
https://phabricator.wikimedia.org/T263527
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tarrow, Pintoch
Cc: Samantha_Alipio_WMDE, Aklapper, Pintoch, Silvan_WMDE
Pintoch added a comment.
I realized today that I have uptime statistics for this service since I have
been monitoring it for a few years (with downnotifier.com).
| Year | Nb of outages | Uptime|
| 2018 | 67| 99.79%|
| 2019 | 324 | 99.09
Pintoch lowered the priority of this task from "Unbreak Now!" to "High".
Pintoch added a comment.
Lowering the priority since the outage seems to have disappeared. Looking at
the #wikimedia-cloud freenode channel this was likely due to a failure to reach
the Kubernetes
Pintoch added a comment.
Probably!
TASK DETAIL
https://phabricator.wikimedia.org/T262553
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Pintoch
Cc: RhinosF1, Pintoch, Aklapper, Nintendofan885, Akuckartz, darthmon_wmde,
Nandana, skpuneethumar
Pintoch added a subtask: T262553: Wikidata reconciliation service unreacheable
(HTTP 502 error), unable to restart the service.
TASK DETAIL
https://phabricator.wikimedia.org/T262550
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Pintoch
Cc
Pintoch added a parent task: T262550: Toolforge returns HTTP 502 error.
TASK DETAIL
https://phabricator.wikimedia.org/T262553
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Pintoch
Cc: Pintoch, Aklapper, Nintendofan885, Akuckartz, darthmon_wmde
Pintoch added a comment.
Another outage today: T262553 <https://phabricator.wikimedia.org/T262553>
(Toolforge-wide ticket: T262550 <https://phabricator.wikimedia.org/T262550>).
TASK DETAIL
https://phabricator.wikimedia.org/T244847
EMAIL PREFERENCES
https://phabricator.w
Pintoch added a comment.
It looks like the services can be reached again now, at least for me.
TASK DETAIL
https://phabricator.wikimedia.org/T262550
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Pintoch
Cc: RhinosF1, Bugreporter, Pintoch
Pintoch created this task.
Pintoch added projects: Toolforge, Wikidata, OpenRefine.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
The Wikidata reconciliation tool currently returns a "502 Bad Gateway" when
requesting its main page: https://wdreconcile.toolforg
Pintoch added a project: Wikidata.
TASK DETAIL
https://phabricator.wikimedia.org/T262550
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Pintoch
Cc: Pintoch, Aklapper, Nintendofan885, Akuckartz, darthmon_wmde, Nandana,
skpuneethumar, Zylc, Bstorm
Pintoch added a comment.
There is also the simpler idea of hosting the existing wrapper as an official
Wikidata service (just like `query.wikidata.org` is an official Wikidata
service, even though Blazegraph is not part of the MediaWiki instance, nor is
maintained by WMDE). Comparing my
Pintoch added a comment.
Thanks @Lydia_Pintscher and sorry for forgetting to tag the issue for
Wikidata.
On my side, I would be keen to transform the wrapper into a Wikibase
extension, but lack the skills to develop in the MediaWiki environment. It is
also a significant risk to invest
Pintoch created this task.
Pintoch added projects: Wikibase - Automated Configuration Detection
(WikibaseManifest), Wikibase - Federated Properties, SDC General, OpenRefine.
Restricted Application added a subscriber: Aklapper.
Restricted Application added a project: Wikidata.
TASK DESCRIPTION
Pintoch added a project: Wikibase - Automated Configuration Detection
(WikibaseManifest).
Pintoch added a comment.
Excited to see the Wikibase team picking up this issue. I am tagging this
ticket with the corresponding project, hoping that this is appropriate?
TASK DETAIL
https
Pintoch added a comment.
Thanks a lot @Lydia_Pintscher !
I have also used this opportunity to optimize the service and deploy it with
ASGI, which Toolforge does not support as far as I know. Perhaps this is an
indication that this should rather be a Cloud VPS project, where we would be
Pintoch removed Pintoch as the assignee of this task.
Pintoch added a comment.
(just removing myself as assignee as I am not expected to work on this task,
I was just available to help during the event)
TASK DETAIL
https://phabricator.wikimedia.org/T207839
EMAIL PREFERENCES
https
Pintoch added a comment.
It appears from T249526 <https://phabricator.wikimedia.org/T249526> that
this is caused by https://gerrit.wikimedia.org/r/586448
TASK DETAIL
https://phabricator.wikimedia.org/T249680
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings
Pintoch updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T249680
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Pintoch
Cc: Afkbrb, Pintoch, Aklapper, darthmon_wmde, WDoranWMF, holger.knust,
EvanProdromou, DannyS712
Pintoch added a comment.
So, if we can track down which MediaWiki commit started to introduce
"set-cookie" headers (instead of "Set-Cookie"), we could hopefully submit a
patch to capitalize it.
The root of the problem lies in the fact that Wikidata-Toolkit uses a
Pintoch updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T249680
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Pintoch
Cc: Afkbrb, Pintoch, Aklapper, darthmon_wmde, Nandana, Lahi, Gq86,
GoranSMilovanovic, QZanden
Pintoch created this task.
Pintoch added projects: Wikidata, OpenRefine.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
Over the past 48 hours, there seems to have been a change in the behaviour of
MediaWiki login API for Wikidata. This causes all logins from Wikidata
Pintoch added a comment.
This does not have anything to do with you indeed! I was just trying to
explain that I stopped trying to help solve this issue (therefore unsubscribing
from this).
TASK DETAIL
https://phabricator.wikimedia.org/T221774
EMAIL PREFERENCES
https
Pintoch added a comment.
I don't know - I stopped working on this task and T240369
<https://phabricator.wikimedia.org/T240369> since T240374
<https://phabricator.wikimedia.org/T240374> was declined. I don't think I can
contribute to solving this problem in the cu
Pintoch added a comment.
It is actually possible to retrieve the current maxlag value from the API
without making any edit (see @Addshore's comment above).
So, just retrieve the current maxlag value and compute your desired edit rate
for this maxlag with the function plotted above.
Pintoch updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T241422
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Pintoch
Cc: Pintoch, darthmon_wmde, Nandana, Mringgaard, Lahi, Gq86, GoranSMilovanovic,
QZanden, LawExplorer
Pintoch created this task.
Pintoch added projects: Lexicographical data, Wikidata.
TASK DESCRIPTION
It looks like this was missed in the resolution of T138104
<https://phabricator.wikimedia.org/T138104>: statements in forms seem to be
still affected by the misuse of empty JSON arrays in
Pintoch created this task.
Pintoch added projects: Toolforge, Wikidata.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
The EditGroups tool <https://tools.wmflabs.org/editgroups/> listens to the
EventStream <https://wikitech.wikimedia.org/wiki/Event_Platform/Eve
Pintoch added a comment.
Thanks! I think dynamically changing the maxlag value is likely to still
introduce some thresholds, whereas a continuous slowdown (by retrieving the lag
and compute one's edit rate based on it) should in theory reach an equilibrium
point.
In the mea
Pintoch added a comment.
Thanks for the analysis! Whether this is a breaking change or not is not my
concern: Petscan and other mass-editing tools based on Widar should play by the
book. I can provide a simple patch which ensures maxlag=5 is applied to all
Widar edits: if someone wants to
Pintoch added a comment.
If clients are able to retrieve the current lag periodically (through some
MediaWiki API call? which one?), then this should not require any server-side
change. Clients can continue to use `maxlag=5` but to also throttle themselves
using the smoothed function
Pintoch created this task.
Pintoch added a project: Wikidata.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
With the introduction of the WDQS lag in Wikidata's maxlag computation
(T221774 <https://phabricator.wikimedia.org/T221774>), we are now seeing the
Pintoch added a comment.
@Bugreporter have you got details of where this behaviour is currently
implemented in PetScan? In particular, how do you request the current maxlag
with the MediaWiki API?
TASK DETAIL
https://phabricator.wikimedia.org/T240370
EMAIL PREFERENCES
https
Pintoch added a comment.
@Theklan let's move your issue to a different ticket as your issue does not
seem to be related: T240436 <https://phabricator.wikimedia.org/T240436>
TASK DETAIL
https://phabricator.wikimedia.org/T197588
EMAIL PREFERENCES
https://phabricator.wikimedia.o
Pintoch added a comment.
I've had a quick look at the code to see if I could submit a patch for this
myself but it is not clear to me where the edits are done - I have looked in
petscan_rs and wikibase_rs to no avail. Petscan edits might be done in the
browser by sending them to some
Pintoch added a comment.
@Bugreporter yes indeed! I was off by one hour there. Thanks for your help!
Feel free to add more bots which match that period.
TASK DETAIL
https://phabricator.wikimedia.org/T240369
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel
Pintoch added a comment.
Matching pull request:
https://github.com/arthurpsmith/author-disambiguator/pull/107
TASK DETAIL
https://phabricator.wikimedia.org/T240371
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: ArthurPSmith, Pintoch
Cc
Pintoch added a comment.
If you have not changed anything in `user-config.py` then you should be good
to go, it might have been a false positive on my side. Sorry for the noise!
TASK DETAIL
https://phabricator.wikimedia.org/T240376
EMAIL PREFERENCES
https://phabricator.wikimedia.org
Pintoch updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T240377
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Magnus, Pintoch
Cc: Aklapper, Pintoch, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86,
GoranSMilovanovic
Pintoch updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T240375
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Bugreporter, Pintoch
Cc: Aklapper, Pintoch, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86,
GoranSMilovanovic
Pintoch updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T240369
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Pintoch
Cc: Pintoch, Aklapper, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86,
GoranSMilovanovic, QZanden
Pintoch created this task.
Pintoch added a project: Wikidata.
TASK DESCRIPTION
Reinheitsgebot edits go through even if maxlag is higher than 5, we should
fix the code to ensure it complies with the maxlag policy on Wikimedia wikis
<https://www.mediawiki.org/wiki/Manual:Maxlag_parameter&
Pintoch created this task.
Pintoch added a project: Wikidata.
TASK DESCRIPTION
LogainmBot edits go through even if maxlag is higher than 5, we should fix
the code to ensure it complies with the maxlag policy on Wikimedia wikis
<https://www.mediawiki.org/wiki/Manual:Maxlag_parameter> by
Pintoch created this task.
Pintoch added a project: Wikidata.
TASK DESCRIPTION
LargeDatasetBot edits go through even if maxlag is higher than 5, we should
fix the code to ensure it complies with the maxlag policy on Wikimedia wikis
<https://www.mediawiki.org/wiki/Manual:Maxlag_parameter&
Pintoch created this task.
Pintoch added a project: Wikidata.
TASK DESCRIPTION
BotMultichill edits go through even if maxlag is higher than 5, we should fix
the code to ensure it complies with the maxlag policy on Wikimedia wikis
<https://www.mediawiki.org/wiki/Manual:Maxlag_parameter&
Pintoch created this task.
Pintoch added a project: Wikidata.
TASK DESCRIPTION
Edoderoobot edits go through even if maxlag is higher than 5, we should fix
the code to ensure it complies with the maxlag policy on Wikimedia wikis
<https://www.mediawiki.org/wiki/Manual:Maxlag_parameter> by
Pintoch assigned this task to Magnus.
TASK DETAIL
https://phabricator.wikimedia.org/T240370
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Magnus, Pintoch
Cc: Aklapper, Pintoch, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86,
GoranSMilovanovic
Pintoch created this task.
Pintoch added a project: Wikidata.
TASK DESCRIPTION
Author Disambiguator edits go through even if maxlag is higher than 5, we
should fix the code to ensure it complies with the maxlag policy on Wikimedia
wikis <https://www.mediawiki.org/wiki/Manual:Maxlag_parame
Pintoch created this task.
Pintoch added a project: Wikidata.
TASK DESCRIPTION
Petscan edits go through even if maxlag is higher than 5, we should fix the
code to ensure it complies with the maxlag policy on Wikimedia wikis
<https://www.mediawiki.org/wiki/Manual:Maxlag_parameter> by
Pintoch created this task.
Pintoch added a project: Wikidata.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
To ensure that Wikidata bot edits slow down when lag is high, we should
ensure that bot operators follow the guidelines which recommend to use the
`maxlag
Pintoch added a comment.
I am first getting in touch with people who seem to be running bots with
maxlag greater than 5 or no maxlag parameter at all, to see if they would
accept to follow @Addshore's advice never to use maxlag greater than 5 at all.
TASK DETAIL
Pintoch added a comment.
OK! If you have ways to check what sort of maxlag values are used it would be
great!
I will try to implement a responsible throttling strategy in OpenRefine,
hoping that others will do the same.
TASK DETAIL
https://phabricator.wikimedia.org/T221774
EMAIL
Pintoch added a comment.
Actually, some tools seem to be doing something like that already, since
edits are still going through despite max lag being above 5 for more than an
hour now (Author Disambiguator does this, QuickStatements too probably,
Edoderoobot too). So these tools use higher
Pintoch added a comment.
One problem with the current policy (requesting all automated editing
processes to use `maxlag=5`) is that this creates a binary threshold: either
the query service lag is under the threshold, in which case bots will edit at
full speed, or the query service lag is
Pintoch added a comment.
So this is what we get with an exponential back-off (1.5 factor), at the
moment:
22:37:27.148 [..baseapi.WbEditingAction] [maxlag] Waiting for all:
5.49167 seconds lagged. -- pausing for 1000 milliseconds. (19338ms)
22:37:28.729
Pintoch added a comment.
Thanks for the notification! I would be happy to release a new version of
OpenRefine with a patch applied - I can do this in the coming days. The
exponential back-off suggested by @Multichill makes sense intuitively - could
WMDE confirm that this is the policy they
Pintoch added a comment.
Thanks! I am working on making OpenRefine easier to host, but it's a long
term project indeed (exciting announcement about that soon).
TASK DETAIL
https://phabricator.wikimedia.org/T238003
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/
Pintoch added a comment.
Exciting developments! I am wondering if that `comment_data` could be (or
already is) exposed in any public API? Exposing such diffs would also solve
T106306 <https://phabricator.wikimedia.org/T106306> in the same go.
As an API consumer I would have a
Pintoch added a comment.
I thought for a moment that there was an issue with the fact that at the
moment, filtering by tags only works for Special:RecentChanges (which only
contain the most recent changes, not all of them). But Lucas pointed out that
it is also supported by
Pintoch added a comment.
Great point! I did not think about that in this way. It sounds like a very
sensible route to follow.
TASK DETAIL
https://phabricator.wikimedia.org/T203557
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Pintoch
Cc: Abit
Pintoch added a comment.
Sure, I hope you don't mind us having this discussion here anyway, since this
is still at a very early stage. (unless you are already planning to work on
this exact architecture?)
TASK DETAIL
https://phabricator.wikimedia.org/T203557
EMAIL PREFERENCES
Pintoch added a comment.
Here are a few issues with the current tool:
- If the tool goes down, this creates millions of dead links in edit
summaries (which cannot be changed). Users who ran batches with the assumption
that they could be undone if something goes wrong find themselves
Pintoch added a comment.
Here is a diff where one of the new fallback summaries failed to be
translated to a human-readable form:
https://www.wikidata.org/w/index.php?title=Property:P571&diff=1040450905&oldid=1038877052
TASK DETAIL
https://phabricator.wikimedia.org/T22069
Pintoch created this task.
Pintoch added a project: Wikibase-Containers.
Restricted Application added a subscriber: Aklapper.
Restricted Application added a project: Wikidata.
TASK DESCRIPTION
**Problem**
Some components (either Wikibase itself or some extensions) rely on special
Pintoch updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T236619
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Pintoch
Cc: Aklapper, Pintoch, darthmon_wmde, Jelabra, DannyS712, Nandana, Lahi, Gq86,
GoranSMilovanovic
Pintoch added a project: OpenRefine.
TASK DETAIL
https://phabricator.wikimedia.org/T197588
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Pintoch
Cc: Nikerabbit, Salgo60, Aklapper, Gstupp, Lucas_Werkmeister_WMDE, Pintoch,
darthmon_wmde
Pintoch added a project: OpenRefine.
TASK DETAIL
https://phabricator.wikimedia.org/T194767
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Pintoch
Cc: Aklapper, Abbe98, Pintoch, Lucas_Werkmeister_WMDE, darthmon_wmde,
Premeditated, Nandana, Lahi
Pintoch added a comment.
On a similar note, we also have some properties whose value is expected to be
the subject entity id:
- https://www.wikidata.org/wiki/Property:P6482
- https://www.wikidata.org/wiki/Property:P6413
TASK DETAIL
https://phabricator.wikimedia.org/T191963
EMAIL
Pintoch added a comment.
That's great! Is there a list of the supported external ids?
TASK DETAIL
https://phabricator.wikimedia.org/T223776
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Danmichaelo, Pintoch
Cc: Pintoch, Lea_Lacroix
Pintoch added a comment.
Thanks all for your patience for this! Excited to see my first commit making
it into Wikibase \o/
TASK DETAIL
https://phabricator.wikimedia.org/T87283
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Pintoch
Cc
Pintoch added a comment.
Ok great! I'll move the field to the end and try to make Jenkins happy then.
TASK DETAIL
https://phabricator.wikimedia.org/T87283
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Pintoch
Cc: Lydia_Pintscher, Pi
Pintoch added a subscriber: Lydia_Pintscher.
Pintoch added a comment.
@Lydia_Pintscher we would need your thoughts about this.
In a nutshell, the proposal is to add the `lastrevid` field currently exposed
in `Special:EntityData` and in the API (`action=wbgetentities`) to the JSON
dumps
Pintoch added a comment.
This is nice! However, when visualizing properties by category, it seems that
subclasses are not taken into account: only the properties bearing that exact
category as P31 <https://phabricator.wikimedia.org/P31> value are listed. This
gives a pretty inaccurat
Pintoch added a comment.
I agree with @Nicolastorzec above.
I suspect that the entity dumps are more popular and cheaper to generate than
the full SQL/XML dumps, so I would argue that they should be generated more
often.
Even if the entity dumps and the SQL/XML dumps were generated
Pintoch added a comment.
@Smalyshev okay! Sorry if this is not the right place: I would be happy to
migrate the patch to another ticket. Indeed this only adds entity-level
metadata, not dump-level metadata. I think this would be less of a breaking
change, given that it does not require
Pintoch added a comment.
I think Wikidata-Toolkit could be used for that:
https://github.com/Wikidata/Wikidata-Toolkit/blob/master/wdtk-rdf/src/main/java/org/wikidata/wdtk/rdf/RdfSerializer.java
Obviously it would mean making sure the RDF serialization produced by it is
consistent with
Pintoch added a comment.
I am wondering what is the status of this: is more discussion needed about
what version information to include, or are we simply waiting for a patch? I
vote for the revision id to serve as version id (possibly with other metadata
such as timestamp, as in
1 - 100 of 170 matches
Mail list logo
