Ladsgroup updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T266703
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Ladsgroup
Cc: Manuel, Ladsgroup, Michael, guergana.tzatchkova, Lydia_Pintscher, Aklapper,
Dzahn, Addshore
Ladsgroup added a comment.
Only https://gerrit.wikimedia.org/r/c/wikidata/query-builder/+/713306 is
waiting to be merged and then it can go to test verification
TASK DETAIL
https://phabricator.wikimedia.org/T266703
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel
Ladsgroup added a comment.
Maybe after a while we should delete the old logs, I can put a reminder to
delete them in three months.
TASK DETAIL
https://phabricator.wikimedia.org/T288175
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Ladsgroup
Cc
Ladsgroup updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T266703
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Ladsgroup
Cc: Manuel, Ladsgroup, Michael, guergana.tzatchkova, Lydia_Pintscher, Aklapper,
Dzahn, Addshore
Ladsgroup updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T266703
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Ladsgroup
Cc: Manuel, Ladsgroup, Michael, guergana.tzatchkova, Lydia_Pintscher, Aklapper,
Dzahn, Addshore
Ladsgroup added a comment.
I'm okay with undeprecating that function but I want to emphasize that even
with using the deprecated function, every edit would trigger a render twice
(three times if you count the edit stash). The xhgui link in the task
description is for when it was using
Ladsgroup added a comment.
Yup:
> This change is currently available for testing at test.wikidata.org. It
will be deployed on Wikidata on August 23rd. You are welcome to give us general
feedback by leaving a comment in this ticket.
TASK DETAIL
https://phabricator.wikimedia.
Ladsgroup added a comment.
The announcement was mentioned 23rd of August as the deploy date. Let me
double check.
TASK DETAIL
https://phabricator.wikimedia.org/T285795
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Ladsgroup
Cc: Thadguidry
Ladsgroup created this task.
Ladsgroup added a project: Wikidata.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
Context: T243051: A query builder for MediaWiki core
<https://phabricator.wikimedia.org/T243051>
Using this would improve our resilience towards mi
Ladsgroup moved this task from Doing to Peer Review on the Wikidata-Campsite
(Wikidata-Campsite-Iteration-∞) board.
Ladsgroup added a comment.
Tested in mwdebug2001 ^ works just fine and finds the stash
TASK DETAIL
https://phabricator.wikimedia.org/T288639
WORKBOARD
https
Ladsgroup added a comment.
At least PageImages only renders the first section, maybe a bit better?
TASK DETAIL
https://phabricator.wikimedia.org/T288639
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Ladsgroup
Cc: toan, Michael, Addshore
Ladsgroup added a comment.
Guess what I found, another extension that trigger an extra render:
https://performance.wikimedia.org/xhgui/run/symbol?id=611a5306f8b9883f5f87dc9e=AbstractContent%3A%3AgetParserOutput
TASK DETAIL
https://phabricator.wikimedia.org/T288639
EMAIL PREFERENCES
Ladsgroup added a comment.
Yes and no. It still shouldn't trigger a double render and use edit stash.
Problem is that Parser just combines everything together.
TASK DETAIL
https://phabricator.wikimedia.org/T288639
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel
Ladsgroup moved this task from Test (Verification) to Doing on the
Wikidata-Campsite (Wikidata-Campsite-Iteration-∞) board.
Ladsgroup added a comment.
Found out why it only improved wikidata editing save time:
F34597546: image.png <https://phabricator.wikimedia.org/F34597546>
TASK
Ladsgroup added a comment.
Except termbox v2, everything is done:
-
https://www.wikidata.org/w/index.php?hidebots=1=1=client-linkitem-change=50=30=1=Special:RecentChanges=2
-
https://www.wikidata.org/w/index.php?hidebots=1=1=client-automatic-update=50=30=1=Special:RecentChanges=2
Ladsgroup added a comment.
The termbox v2 fails:
{"error":{"code":"badtags","info":"The tag \"wikidata-ui,termbox\" is not
allowed to be manually
applied.","disallowedtags":["wikidata-ui,termbox"],"*
Ladsgroup added a comment.
I want to start with something simple and slowly migrate to something more
complex. Specially since basically every interaction's bottleneck is API
response time (e.g. for lookup for property ID, loading the WDQS results, etc.)
and not the app itself. Other reason
Ladsgroup added a comment.
Going to deploy this soon
TASK DETAIL
https://phabricator.wikimedia.org/T236893
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Ladsgroup
Cc: Ladsgroup, Mohammed_Sadat_WMDE, GoranSMilovanovic, jhsoby, hoo, David
Ladsgroup added a comment.
I mean `!important` is evil but I don't know a better alternative atm :/ I
can take a look at it but I doubt I would be able to come up with a solution
tbh.
TASK DETAIL
https://phabricator.wikimedia.org/T287206
EMAIL PREFERENCES
https
Ladsgroup added a comment.
AWESOOOME
itshappening
<https://phab.wmfusercontent.org/file/data/h7d6lnz2jc336a7pxovg/PHID-FILE-2pdqntdsdx6ayairzvuz/meme-itshappeningjimmy.png>
TASK DETAIL
https://phabricator.wikimedia.org/T264822
EMAIL PREFERENCES
https://phabricator.wikimed
Ladsgroup added a comment.
Thanks. I started it, the problem is that the URL is not up so we can't merge
the patches, I hope I did them correctly at least. Does that look correct to
you?
TASK DETAIL
https://phabricator.wikimedia.org/T287769
EMAIL PREFERENCES
https
Ladsgroup moved this task from Peer Review to Test (Verification) on the
Wikidata-Campsite (Wikidata-Campsite-Iteration-∞) board.
Ladsgroup added a comment.
Some nice numbers
https://grafana.wikimedia.org/d/00559/api-requests-breakdown?viewPanel=19=1=1628763472923=1628842508524=p95
Ladsgroup added a subscriber: Lucas_Werkmeister_WMDE.
Ladsgroup added a comment.
@Lucas_Werkmeister_WMDE suggested we can still trigger a double render but
with generate_html to false for SpamBlacklist which would speed it up
drastically.
TASK DETAIL
https://phabricator.wikimedia.org
Ladsgroup added a comment.
Yup, `AbstractContent::getParserOutput` creates a new PO, renders it and send
it back every time it's called and it's called in lots of places.
TASK DETAIL
https://phabricator.wikimedia.org/T288639
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings
Ladsgroup added a comment.
The calls to that certain part has been removed but the save timing hasn't
improved. My working hypothesis is that I just moved double rendering from one
function call to another. Is there any function in mediawiki that wouldn't
trigger a render?
TASK DETAIL
Ladsgroup added a comment.
I don't know how it managed to caused such a big fix for wikidata but it is
the result of before and after:
https://performance.wikimedia.org/xhgui/run/symbol?id=6114280a2df779cbf2be4232=MediaWiki%5CRevision%5CRenderedRevision%3A%3AgetSlotParserOutput
https
Ladsgroup added a comment.
I see that the patch doesn't change any behavior (and doesn't let you save
page with spam in them) while reducing the CPU time to half and wall time drops
drastically as well:
To compare, these two are basically the try of the same edit, one with the
patch
Ladsgroup added a subtask: T288639:
SpamBlacklistHooks::onEditFilterMergedContent causes every edit to be rendered
twice.
TASK DETAIL
https://phabricator.wikimedia.org/T285987
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Ladsgroup
Cc: danshick
Ladsgroup added a comment.
This is wy more complicated than it looks, I try to summarize my findings
here:
- First, if we fix this, and taking editing the sandbox as an example, the
wall time will be reduced by 33% and CPU time by 40% (data
<https://performance.wikimedia.org/xh
Ladsgroup added a comment.
itshappening
<https://phab.wmfusercontent.org/file/data/h7d6lnz2jc336a7pxovg/PHID-FILE-2pdqntdsdx6ayairzvuz/meme-itshappeningjimmy.png>
TASK DETAIL
https://phabricator.wikimedia.org/T204031
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings
Ladsgroup claimed this task.
Ladsgroup moved this task from To Do (prioritised from top to bottom) to Doing
on the Wikidata-Campsite (Wikidata-Campsite-Iteration-∞) board.
Restricted Application added a project: User-Ladsgroup.
TASK DETAIL
https://phabricator.wikimedia.org/T285987
WORKBOARD
Ladsgroup moved this task from Doing to Peer Review on the Wikidata-Campsite
(Wikidata-Campsite-Iteration-∞) board.
Ladsgroup added a comment.
I cannot check if the job succeeded but I can see the links got updated:
MariaDB [zhwiktionary_p]> select * from page where page_ti
Ladsgroup added a comment.
I understand but my point is that if you need rate more than 1, you probably
need a separate job runner (which can be very easily setup, probably even in
docker-compose as part of our official release)
TASK DETAIL
https://phabricator.wikimedia.org/T255259
EMAIL
Ladsgroup added a comment.
Another thing: The six hour maximum is not true, I have found jobs with roots
that go back maybe five days before.
TASK DETAIL
https://phabricator.wikimedia.org/T278924
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences
Ladsgroup added a comment.
So I see jobs being triggered. I'm not sure if they succeed or not:
ladsgroup@stat1005:~$ kafkacat -b kafka-main2001.codfw.wmnet -p 0 -t
'codfw.mediawiki.job.refreshLinks' -o -10 | grep -i BadTitle | head
{"$schema":"/mediawiki/j
Ladsgroup added a comment.
That would be weird and interesting and at best would be relying on the
webserver's traffic (otherwise, how Apache would know to run the job?). If a
server is scaling out that (which I'm surprised even exists), the right way is
to have a job runner (as a minutely
Ladsgroup added a comment.
It might sound stupid and you probably know this already and I'm really sorry
for repeating something you know already but in your localhost, no job is being
ran unless you run runJobs.php. Right?
If you have some systems in docker to run jobs, you can just
Ladsgroup added a comment.
Some fancy graphs:
F34588490: image.png <https://phabricator.wikimedia.org/F34588490>
https://grafana.wikimedia.org/d/00344/wikidata-quality?orgId=1=1628419581197=1628505226141
F34588492: image.png <https://phabricator.wikimedia.org/
Ladsgroup claimed this task.
Ladsgroup moved this task from To Do (prioritised from top to bottom) to Doing
on the Wikidata-Campsite (Wikidata-Campsite-Iteration-∞) board.
Restricted Application added a project: User-Ladsgroup.
TASK DETAIL
https://phabricator.wikimedia.org/T278924
WORKBOARD
Ladsgroup changed the task status from "Stalled" to "Open".
Ladsgroup claimed this task.
Ladsgroup moved this task from Stalled/Waiting to Doing on the
Wikidata-Campsite (Wikidata-Campsite-Iteration-∞) board.
Restricted Application added a project: User-Ladsgroup.
Ladsgroup changed the status of subtask T204031: Deploy regular running of
wikidata constraint checks using the job queue from Stalled to
Open.
TASK DETAIL
https://phabricator.wikimedia.org/T201150
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences
Ladsgroup added a comment.
In T264822#7245462 <https://phabricator.wikimedia.org/T264822#7245462>,
@Ladsgroup wrote:
> We migrated to vite/rollup and here is the build patch for review:
https://gerrit.wikimedia.org/r/c/wikidata/query-builder/deploy/+/708629
>
> I'm
Ladsgroup added a comment.
You can easily reproduce the problem by going to any page linked in
Special:UnconnectedPages. This would make finding the issue easier.
TASK DETAIL
https://phabricator.wikimedia.org/T287206
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel
Ladsgroup claimed this task.
Restricted Application added a project: User-Ladsgroup.
TASK DETAIL
https://phabricator.wikimedia.org/T288175
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Ladsgroup
Cc: Aklapper, Addshore, Ladsgroup, Legoktm, Biggs657
Ladsgroup moved this task from Doing to Test (Verification) on the
Wikidata-Campsite (Wikidata-Campsite-Iteration-∞) board.
Ladsgroup added a comment.
No the delete hook (`ArticleDeleteCompleteHook`) is synchronous as far as I
can see.
TASK DETAIL
https://phabricator.wikimedia.org/T268135
Ladsgroup edited projects, added Wikidata-Campsite; removed Wikidata-Campsite
(Wikidata-Campsite-Iteration-∞).
Ladsgroup removed Mbch331 as the assignee of this task.
TASK DETAIL
https://phabricator.wikimedia.org/T288335
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel
Ladsgroup added a comment.
Thanks <3
TASK DETAIL
https://phabricator.wikimedia.org/T285104
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Legoktm, Ladsgroup
Cc: Joe, Michael, JMeybohm, Addshore, Lucas_Werkmeister_WMDE, Aklapper,
Lego
Ladsgroup added a comment.
For now:
F34585538: image.png <https://phabricator.wikimedia.org/F34585538>
Will be interesting once we ramp it up to 100% which we will in Monday.
TASK DETAIL
https://phabricator.wikimedia.org/T176312
EMAIL PREFERENCES
https://phabricator.wikimed
Ladsgroup added a comment.
Working now:
https://performance.wikimedia.org/xhgui/run/symbol?id=610c034bf894a311aa98d32c=WikibaseQuality%5CConstraintReport%5CConstraintCheck%5CChecker%5CFormatChecker%3A%3ArunRegexCheckUsingShellbox
I will deploy it fully on test wikidata and 1% on wikidata
Ladsgroup added a comment.
(Not speaking on behalf of the team, completely personal):
I see three way out that we could talk about and decide:
- Get SRE/Security/Legal approval for a temporary deployment of reading for
wmcs. One idea I have to ease and compromise is to have a fixed
Ladsgroup added a comment.
This is going to get replaced with jobs soon (maybe in a couple of months) so
I wouldn't put too much work in it. Having three systemd timers sounds much
easier to implement.
TASK DETAIL
https://phabricator.wikimedia.org/T288175
EMAIL PREFERENCES
https
Ladsgroup added a comment.
It's a bit hard to implement this as systemd timers are not concurrent and
the crons here are designed to be three at the same time. Finding a solution
for it should be easy though (famous last words)
TASK DETAIL
https://phabricator.wikimedia.org/T288175
EMAIL
Ladsgroup moved this task from Peer Review to Doing on the Wikidata-Campsite
(Wikidata-Campsite-Iteration-∞) board.
Ladsgroup added a comment.
let me check the deletion hook.
TASK DETAIL
https://phabricator.wikimedia.org/T268135
WORKBOARD
https://phabricator.wikimedia.org/project/board
Ladsgroup moved this task from Peer Review to Stalled/Waiting on the
Wikidata-Campsite (Wikidata-Campsite-Iteration-∞) board.
Ladsgroup added a comment.
Let's see if it fixes things.
TASK DETAIL
https://phabricator.wikimedia.org/T277862
WORKBOARD
https://phabricator.wikimedia.org
Ladsgroup claimed this task.
Ladsgroup moved this task from To Do (prioritised from top to bottom) to Peer
Review on the Wikidata-Campsite (Wikidata-Campsite-Iteration-∞) board.
Ladsgroup added a comment.
Cookie devouring
TASK DETAIL
https://phabricator.wikimedia.org/T277862
WORKBOARD
Ladsgroup added a comment.
As the unstaller this week. What can I do to move this forward?
TASK DETAIL
https://phabricator.wikimedia.org/T285098
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Ladsgroup
Cc: Ladsgroup, Ottomata
Ladsgroup added a comment.
I'm not sure if it's worth doing now. Possibly due to lots of refactoring
that page I linked is now only call that function 50 times instead of 9k times.
Even for Alan Turing category which has a quite large data it calls it 800
times and takes 2ms (in a request
Ladsgroup added a comment.
I haven't forgotten about this. It's just that no one has looked at my patch
to see if it'll work or not :(
TASK DETAIL
https://phabricator.wikimedia.org/T285049
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences
Ladsgroup claimed this task.
Ladsgroup added a comment.
Restricted Application added a project: User-Ladsgroup.
In T268135#7252426 <https://phabricator.wikimedia.org/T268135#7252426>,
@Lucas_Werkmeister_WMDE wrote:
> In T268135#7252244 <https://phabricator.wikimedia.org/T26
Ladsgroup added a comment.
In T280910#7255504 <https://phabricator.wikimedia.org/T280910#7255504>,
@Lucas_Werkmeister_WMDE wrote:
> Entity usage on my sandbox page
<https://www.wikidata.org/w/index.php?title=User:Lucas_Werkmeister_(WMDE)/sandbox=info>
loo
Ladsgroup added a comment.
The plan is basically to deploy it really soon. I can't talk on behalf of
WMDE on the final day but it's basically as soon as possible (specially since
the security readiness review is done)
TASK DETAIL
https://phabricator.wikimedia.org/T287769
EMAIL
Ladsgroup added a comment.
There is a basically exact same situation with
`wikibase-after-page-delete-queued` as well. I have to check the hook handlers
to be sure but if you know on top of your head that it's the case or not. Let
me know.
TASK DETAIL
https://phabricator.wikimedia.org
Ladsgroup claimed this task.
Ladsgroup moved this task from To Do (prioritised from top to bottom) to Peer
Review on the Wikidata-Campsite (Wikidata-Campsite-Iteration-∞) board.
Restricted Application added a project: User-Ladsgroup.
TASK DETAIL
https://phabricator.wikimedia.org/T250928
Ladsgroup reassigned this task from Ladsgroup to Michael.
Ladsgroup added a comment.
Restricted Application added a project: User-Michael.
Michael is writing the regression tests.
TASK DETAIL
https://phabricator.wikimedia.org/T287704
EMAIL PREFERENCES
https://phabricator.wikimedia.org
Ladsgroup moved this task from Peer Review to Doing on the Wikidata-Campsite
(Wikidata-Campsite-Iteration-∞) board.
Ladsgroup added a comment.
Technically doing, the patch is not ready for review.
TASK DETAIL
https://phabricator.wikimedia.org/T287704
WORKBOARD
https
Ladsgroup added a comment.
Performance review: T287769: Performance review of Query Builder
<https://phabricator.wikimedia.org/T287769>
TASK DETAIL
https://phabricator.wikimedia.org/T264822
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailprefe
Ladsgroup created this task.
Ladsgroup added projects: Performance-Team, Wikidata Query Builder, Wikidata.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
Description
---
//(Please provide the context of the performance review, and describe how
Ladsgroup moved this task from Peer Review to Test (Verification) on the
Wikidata-Campsite (Wikidata-Campsite-Iteration-∞) board.
Ladsgroup added a comment.
I think the ticket is done, I leave it to my fellow campers and @Addshore to
close it or not. The patch wasn't a band-aid.
TASK DETAIL
Ladsgroup claimed this task.
Restricted Application added a project: User-Ladsgroup.
TASK DETAIL
https://phabricator.wikimedia.org/T287704
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Ladsgroup
Cc: Michael, Aklapper, mmodell, Biggs657, Invadibot
Ladsgroup added a project: Wikidata-Campsite (Wikidata-Campsite-Iteration-∞).
TASK DETAIL
https://phabricator.wikimedia.org/T287704
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Ladsgroup
Cc: Michael, Aklapper, mmodell, Biggs657, Invadibot
Ladsgroup claimed this task.
Ladsgroup moved this task from To Do (prioritised from top to bottom) to Doing
on the Wikidata-Campsite (Wikidata-Campsite-Iteration-∞) board.
Restricted Application added a project: User-Ladsgroup.
TASK DETAIL
https://phabricator.wikimedia.org/T286773
WORKBOARD
Ladsgroup added a comment.
We migrated to vite/rollup and here is the build patch for review:
https://gerrit.wikimedia.org/r/c/wikidata/query-builder/deploy/+/708629
I'm about to create a performance review ticket now.
TASK DETAIL
https://phabricator.wikimedia.org/T264822
EMAIL
Ladsgroup claimed this task.
Ladsgroup moved this task from To Do (prioritised from top to bottom) to Doing
on the Wikidata-Campsite (Wikidata-Campsite-Iteration-∞) board.
Ladsgroup added a comment.
Restricted Application added a project: User-Ladsgroup.
I'm doing this already. Slow
Ladsgroup added a comment.
In T285104#7239822 <https://phabricator.wikimedia.org/T285104#7239822>, @Joe
wrote:
> I think there are two options, depending on the level of security we want
to achieve and the urgency of bringing this to production:
>
> 1. We just point
Ladsgroup updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T287438
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Ladsgroup
Cc: Michael, Addshore, Aklapper, Ladsgroup, Invadibot, maantietaja, Akuckartz,
Nandana, Lahi
Ladsgroup added a comment.
I'm on it
TASK DETAIL
https://phabricator.wikimedia.org/T285104
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Ladsgroup
Cc: Michael, JMeybohm, Addshore, Lucas_Werkmeister_WMDE, Aklapper, Legoktm,
Ladsgroup
Ladsgroup added a comment.
In T277862#7212305 <https://phabricator.wikimedia.org/T277862#7212305>, @toan
wrote:
> Moving this back to the todo column as we wanna make an attempt at running
a trimmed down suite against beta instead of running all the specs.
I looked at w
Ladsgroup created this task.
Ladsgroup added a project: Wikidata.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
A considerable number of Integration API tests in Wikibase are basically
trying to call an API endpoint and check the result.
Due to its nature
Ladsgroup claimed this task.
Restricted Application added a project: User-Ladsgroup.
TASK DETAIL
https://phabricator.wikimedia.org/T285795
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Ladsgroup
Cc: Esc3300, Mohammed_Sadat_WMDE, toan, Aklapper
Ladsgroup moved this task from Stalled/Waiting to Needs Announcement on the
Wikidata-Campsite (Wikidata-Campsite-Iteration-∞) board.
Ladsgroup added a comment.
Deployed on testwikidatawiki:
An example of TTL output:
| Page| Before | After |
| https
Ladsgroup added a comment.
In T286777#7236131 <https://phabricator.wikimedia.org/T286777#7236131>,
@Lucas_Werkmeister_WMDE wrote:
> Let’s call this done, we’ll see in the parent tasks if it works or not.
Shouldn't we update the submodule? :D
TASK DETAI
Ladsgroup added a comment.
In T285987#7227115 <https://phabricator.wikimedia.org/T285987#7227115>,
@Kormat wrote:
> In T285987#7215913 <https://phabricator.wikimedia.org/T285987#7215913>,
@Ladsgroup wrote:
>
>> My guess would be that this will remove around a
Ladsgroup added a parent task: T287319: Post-creation work for jvwikisource.
TASK DETAIL
https://phabricator.wikimedia.org/T286248
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Ladsgroup
Cc: Maintenance_bot, Aklapper, Invadibot, maantietaja
Ladsgroup closed this task as "Resolved".
Ladsgroup added a comment.
The offset bit in jquery.ui is fixed.
TASK DETAIL
https://phabricator.wikimedia.org/T185629
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Ladsgroup
Cc: Ladsgr
Ladsgroup added a comment.
The patch I put up responds with all languages of the fallback chain so if
you ask for Austrian German, the labels and descriptions for Austrian German,
German and English will be returned regardless if the entity already has the
label in Austrian German
Ladsgroup added a comment.
So I tried this patch on mwdebug2001.
It makes Q30.rdf from 29MB to 7.2MB. I upload the result to compare:
https://people.wikimedia.org/~ladsgroup/Q30-new.rdf
Q7251 went from 7MB to 2MB:
https://people.wikimedia.org/~ladsgroup/Q7251-new.rdf and
https
Ladsgroup added a comment.
I've been running it for years now, I have seen it break I think last month
too while it's rather rare. The problem is that you need to run this for +1k
wikis and well, some would not work for any number of reasons and it would
break the whole wiki. The proper fix
Ladsgroup moved this task from Doing to Test (Verification) on the
Wikidata-Campsite (Wikidata-Campsite-Iteration-∞) board.
Ladsgroup reassigned this task from Ladsgroup to Michael.
Ladsgroup added a comment.
Most of the work was done by Michael, I did the last pushes.
TASK DETAIL
https
Ladsgroup added a comment.
Yeah, we're looking at it :D It will take a bit of time, there some open
questions like LVS or ingress we need to adrress
TASK DETAIL
https://phabricator.wikimedia.org/T285104
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences
Ladsgroup added a comment.
The first option has this downside that for connected pages to wikidata items
(majority of Wikipedia articles) you will see two links to the exactly same
thing (the wikidata item):
F34552431: image.png <https://phabricator.wikimedia.org/F34552431>
The
Ladsgroup added subscribers: LSobanski, Marostegui.
Ladsgroup added a comment.
I just want to say that I think the effect on readers will be negligible,
HTML of entity content comparing to wikitext is much faster to produce.
Also there is a rather major benefit from
Ladsgroup lowered the priority of this task from "Unbreak Now!" to "High".
TASK DETAIL
https://phabricator.wikimedia.org/T286679
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Ladsgroup
Cc: Urbanecm, Zabe, AntiCompositeNumb
Ladsgroup added a comment.
In T286679#7215279 <https://phabricator.wikimedia.org/T286679#7215279>,
@Urbanecm wrote:
> Given it's a train blocker, can we reimport at least core's translations
from TWN and just backport that patch? Not sure how easy it would be to
backp
Ladsgroup added a comment.
We can deploy this tomorrow
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/704612 It
needs a l10n rebuild that usually takes a while.
TASK DETAIL
https://phabricator.wikimedia.org/T286679
EMAIL PREFERENCES
https://phabricator.wikimedia.org
Ladsgroup added a project: Language-Team.
TASK DETAIL
https://phabricator.wikimedia.org/T286679
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Ladsgroup
Cc: Ladsgroup, RhinosF1, LucasWerkmeister, Nikki, Aklapper, Invadibot,
PallaviPatke
Ladsgroup added a comment.
It's affecting wikidata but it's not a bug of Wikibase code:
https://de.wikibooks.org/w/index.php?title=MediaWiki:Wikibase-sitelinks-wikinews/en-gb
I don't think there is much the wikidata team can do here
TASK DETAIL
https://phabricator.wikimedia.org
Ladsgroup added projects: I18n, MediaWiki-Internationalization.
TASK DETAIL
https://phabricator.wikimedia.org/T286679
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Ladsgroup
Cc: Ladsgroup, RhinosF1, LucasWerkmeister, Nikki, Aklapper, Invadibot
Ladsgroup claimed this task.
Ladsgroup moved this task from Peer Review to Doing on the Wikidata-Campsite
(Wikidata-Campsite-Iteration-∞) board.
Ladsgroup added a comment.
Restricted Application added a project: User-Ladsgroup.
Adding the one language feature flag and setup now.
TASK DETAIL
Ladsgroup added a comment.
In T282026#7212089 <https://phabricator.wikimedia.org/T282026#7212089>,
@Jdlrobson wrote:
> In T282026#7211929 <https://phabricator.wikimedia.org/T282026#7211929>,
@GiorgiOkropiridze wrote:
>
>> None of them work. Both of these
Ladsgroup added a comment.
Tomorrow all metrics starting with `wikibase.queryService.ui.app.` should be
migrated to `wikibase.queryService.ui.index.app.` I will deploy it around 8:30
UTC
TASK DETAIL
https://phabricator.wikimedia.org/T272128
EMAIL PREFERENCES
https
301 - 400 of 4855 matches
Mail list logo
