Hmm, it appears to have fixed itself right now ?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Tue, Apr 23
Sun, Apr 21
@Samwilson Could we load the config directly from the OCR tool ?
Sat, Apr 20
Maybe we can use client-side JS indicators (like the number/sizes/pattern of copy-pastes a user does and the amount of subsequent editing done to the passage) to track/flag articles as being potentially pasted from other sources (it wouldn't be a direct admission of using GPT, but could be a probable metric to look at) ?
Fri, Apr 19
In T362473#9711646, @Novem_Linguae wrote:Has this worked in the past?
If so, let's 1) add a regression tag and 2) git bisect to figure out the patch that introduced the bug. This patch looks like it might have touched some code related to this.
Wed, Apr 17
@Jdlrobson Could you take a look at the patch if the cherry pick/backport was setup correctly ?
Tue, Apr 16
In T348078#9720758, @Jdlrobson wrote:@Soda let me know if you need any help reviewing or documenting these APIs and preparing backports. Happy to help!
Unrelated to this, there is a bunch of scripts on wikisource that use $( '.prp-page-image img' ).attr( 'src' ) which would probably go against the stable interface policy :( These should probably be asked to change over to the mw.proofreadpage.openseadragon API.
This is probably OSD being weird :(
Taking a look at the rest:
- ext.proofreadpage.osd-no-image-found should be fine to have around. That code path does get exercised (Thumbor is notoriously unstable for Wikisource).
- ext.proofreadpage.page-selection-register-filter is part of a beta feature, but is mostly stable, no issues there
- ext.proofreadpage.osd-controller-available is very stable no issues there
Regarding mw.proofreadpage:
- mw.proofreadpage.PagelistInputWidget most of this is supposed to be internal and probably needs to be removed unless somebody legitimately uses this (I do not know if anyone does)
- mw.proofreadpage.viewer is deprecated and has been for a while
- mw.proofreadpage.openseadragon is stable and has been for a while
- mw.proofreadpage.PageQualityInputWidget is internal and probably should not be exposed. (I'm pretty sure nobody uses this since it was introduced fairly recently in T344928)
Similarly proofreadpage-openseadragon-no-image-found is not a API that is provided by ProofreadPage. I'm super confused where these are showing up.
@Jdlrobson What/where is mw.ext.proofreadPage being created ?
Wed, Apr 10
@Novem_Linguae How does twinkle handle this case ?
Fri, Apr 5
Merged :)
Wed, Apr 3
Tue, Apr 2
Wsstats just subtracts one from the totals we get :)
Fri, Mar 29
Noting that the last time I checked, this worked on safemode as well.
Thu, Mar 28
Wed, Mar 27
Looks good to me overall, I'd suggest explicitly mentioning the project size. If you are planning for a large project, you do have time until early November.
Mar 26 2024
Boldly un-closing. The workaround identified here is wiki specific and does not address the root cause of the problem. I would assume a code change in the WS Export tool would be required.
My hypothesis here is that the options module ext.pageTriage.externalTagsOptions for PageTriage is being considered a user-generated javascript bundle somehow. The class that loads the options, PageTriageExternalTagsOptions extends from the WikiModule class which is also appears to be used to load userjs and sitecss. I wonder if it might be setting some kind of variable flagging the module as a user-generated module.
Mar 24 2024
@Maunikashekar I would suggest:
- Expanding on how you plan on implement some of the deliverables mentioned in the original project task
- Clearly specifying the project size.
- Potentially spacing out the tasks if you are going for a large sized project, since you do get time until November to complete all the deliverables (for example you mention that you plan on implementing "keyword search for New Pages Feed" in a week, imo, that might be a bit optimistic, since such a task will require filing a database modification request which takes time to be actioned).
@Prati28 What project size are you aiming for ? I would suggest spacing out your timelines to account for delays and back-and-forth. Also, note that for large projects, you should be able to plan out your timeline early November (In case you need more time).
Mar 23 2024
Mar 22 2024
I think this has already been resolved by the VueJS migration
Mar 19 2024
Mar 18 2024
Mar 16 2024
In T319965#9633459, @Tpt wrote:@Soda Amazing! Thank you! A user request from French Wikisource: Would it be possible to add to the website plots for all the wikisources (a line per wiki)? And the data in a table format instead of charts (I guess just allowing to download a csv is fine)?
Mar 15 2024
In T357337#9633256, @Prati28 wrote:Hi @Soda, I'm working on the first pre-GSoC task. Due to CORS restrictions, I'm unable to receive responses from the URL. Should I consider implementing a backend solution using PHP or Node.js, or should I use a CORS proxy?
Mar 14 2024
I've been able to fork off the statistics stuff to https://wsstats.toolforge.org (mostly). (I did look into migrating it, but had difficulty even identifying which files reference what)
Boldly changing this to open. While the grid engine might have shut down, there still a need to migrate usable functionality off phetools. (For example, the statistics component is actively being migrated (by me), see the wsstats toolforge tool account). I am not sure what tool this should be categorised under, but I don't think Declined correctly reflects the current state.
Mar 13 2024
Mar 11 2024
Mar 10 2024
In T357337#9618296, @Rockingpenny4 wrote:@Soda , I already have mediawiki setup and will proceed with the PageTriage Extension installation . I have previously contributed to WikiEduDashboard and InlineComments Extension under Wikimedia, that being said , will my previous contributions help my proposal being selected?
Mar 8 2024
In T357770#9615192, @Sgurrdearg wrote:This still is not resolved? The font size is still way too big, and it is noticeably bigger than before all the changes. You’ve done absolutely nothing to fix it. As I stated, I have checked this on other devices and confirmed that this is persistent and not linked to my phone settings at all, despite @Jdlrobson’s incorrect assumption.
Mar 5 2024
@AhmedSobhyOfficial Take a look at Special:NewPagesFeed on the English Wikipedia to see the current extension and how it works :)
Mar 3 2024
Noting that this article appears to have been "patrolled" as opposed to "reviewed" see this query
Mar 1 2024
Feb 29 2024
@Bicolino34 Can you take a screenshot of the page in this state ?
Feb 25 2024
Feb 16 2024
The line height is indeed harder to read than the original. I would be in favour of keeping the original line heights.
https://phabricator.wikimedia.org/P56878 is the timeout error in case that is interesting :)
I'm having/had similar issues with Redis on qpqtool it seems like provisioning a fresh connection per request help, but that does not seem to be the recommended method of using redis-py.
Feb 15 2024
https://discord.com/channels/221049808784326656/221060705078476801/1207769970696519710 would be the start of the messages in question. The major criticism is that the paragraphs are too dense and the line spacing is too small.
Based on some initial tests, it seems like the problem here is that people who had previous intentionally set the font to "Regular" (renamed "Standard" now) are now getting a bigger font instead of the "Small" font (which is now the default font).
There has been some feedback on the Wikimedia Discord community that this particular change makes the text very hard to read.
Feb 14 2024
This should be done based on the merged PR and the lack of jobs at https://grid-deprecation.toolforge.org/t/croptool. There are still a few issues (namely with the magic border locator and some issues with persistent sessions) that need to be looked into/fixed. However, those can be dealt with followup patches.
Feb 13 2024
In T319965#9536707, @Xover wrote:In T319965#9534722, @Soda wrote:I'm looking into migrating some of the usable aspects (statistics and match + split) of phetools into seperate standalone tools. This might take a while however, so I'd like to request that the tool be kept running after the Feb 14th shutdown deadline.
If all you're doing is forking bits and pieces of it into separate tools you should be able to do that without having phetools running on Grid Engine. I presume "shutting down the tool" means preventing it from spawning Grid Engine jobs, not deleting or making inaccessible the tool's account or code.
However, I still plan to try to port phetools entire to the Jobs Framework++ when I can find the time to sit down with it, so having an extension for that purpose would be appreciated.
Feb 12 2024
I'm looking into migrating some of the usable aspects (statistics and match + split) of phetools into seperate standalone tools. This might take a while however, so I'd like to request that the tool be kept running after the Feb 14th shutdown deadline.
Feb 7 2024
In T356759#9519308, @egardner wrote:Hey @taavi, I posted a patch to PageTriage that fixes this issue. I resorted to a "brute force" solution where I simply scrapped the old package-lock.json, updated the dependencies manually, and then ran npm install to re-create it. If that's not an approach that you want to take, hopefully the patch (and it's accompanying package-lock.json file) will be useful in further debugging here.
After updating Vue and Codex for this project, I found that npm run test was throwing errors; ESLint was failing to parse the Vue files. I've remedied this by adding ESLint Plugin Vue to package.json as a dev dependency as well.
I didn't run this code or inspect it deeply, so I'd recommend spinning this up in a properly-provisioned local environment; all I did was confirm that npm install and npm run test could execute without errors. Several Codex components have changed between v0.14 and v1.3.1 (you can see the full changelog here) so there may be visual changes even if no functionality you rely on has broken.
Feb 5 2024
This link is called "Mute preferences" in non en-wiki instances.
Feb 4 2024
Tentatively tagging anti-harrasment, not sure which component this belongs to.
Feb 2 2024
This is not a Opeseadragon issue, this is probably a issue with commons rendering of thumbnails
In T325607#9440813, @SCherukuwada wrote:Here is a summary of our discussions with Google (they proofread this summary):
The web is really large and the search index can simply not include every single page. A page that otherwise has no problems may not be indexed for a myriad of complex reasons, for instance if the indexing process determines that the page is unlikely to be requested in search. This is in line with the Search Central documentation that states: "Google doesn't guarantee that it will crawl, index, or serve your page, even if your page follows the Google Search Essentials."
Google also shared a document containing resource links.
They encouraged using SEO Office Hours hosted by Google. And it comes with a disclaimer saying that they might not be able to answer all questions in a given instance.
Resources on Google Search.pdf33 KBDownload
Feb 1 2024
Jan 31 2024
@Danmichaelo I've raised a PR at https://github.com/danmichaelo/croptool/pull/192 to merge my changes into the croptool tree. Everything except the tests should work (will try and work on them once I'm confident everything else works).
Jan 29 2024
I'm still working on this off and on, but migrating the app is a bit more involved since php7.4 is not availiable when building with buildpacks.
Jan 23 2024
In T355575#9480311, @dcaro wrote:Had a quick look at the code, I see also that there's a lot going on on the start script, you should try to move as much as you can to the build steps instead, otherwise they will run every time you start/stop the process.
For example, nodejs/npm installation is done already by the nodejs buildpack, composer installation+deps also, you are probably able to move the pecl scripts as part of nodejs or composer build scripts.
In T355575#9480266, @dcaro wrote:If this is in order to compile jpetrans on the fly, you can try using the ubuntu package instead: https://launchpad.net/ubuntu/trusty/+package/libjpeg-turbo-progs
C/C++ are not supported langs, so we don't have a nice way of compiling those yet.
Possibly the fix for T353847 isn’t handling virtual packages correctly yet?
Yep, it is probably not, will look into it eventually, we don't want though to support a fully debian installation system, using the Apt buildpack is a workaround for edge-case scenarios where you are not using the lang's package management, so many edgecases that are not supported are to be expected.
Btw @nskaggs would it be possible to keep the tool's services running for now, since this is a widely used tool ?
I did take a look at this, but I'm currently blocked on T355575: [apt-buildpack] Does not handle virtual packages correctly
Jan 22 2024
In T355519#9476166, @Peachey88 wrote:I was able to do it on Tool-link-dispenser, I don't have anything other than Trusted-Contributors similar to @Soda.
@Soda what project did you attempt this one?
Jan 16 2024
Jan 15 2024
@Frostly, @HouseBlaster's recent config change already allows anyone to thank any bot on any Wikimedia wiki. (See this log action by me thanking your bot on enwiki).
Jan 14 2024
Based on a few tests wrt to EranBot this appears to work.
Jan 8 2024
Few points that probably need to be resolved:
Adding a rest API that allows pinging arbitrary editors is not a great idea(Fixed by @Vikipolimer in this patch)- Loading configuration via this method isn't going to do wonders for page startup times, I'd suggest using packageFiles to load the config instead.
Jan 6 2024
In T334549#9439146, @Novem_Linguae wrote:
- How does the pagetriagetagcopyvio API work? On a page with multiple revisions, I tried tagging the top revision and bottom revision as copyright violations, and I could not get PageTriage to display the "copyvio" tag. Then I figured out to set $wgPageTriageEnableCopyvio = true; but was getting inconsistent results. I will probably have to go read the code to figure out how this works. There may be a bug here.
Huh, I do see this as well, I will poke at this sleeping dragon, hopefully, if thing go well, it will not transfigure into a can of worms.
@Izno I wonder if we can use a div/span implementation and use role=progressbar and a aria-describedby ?
Jan 3 2024
In T354267#9433291, @Izno wrote:I have done something like this in the progression rainbow module, for anyone who looks into this.