CropTool has been having similar issues and is unable to connect to mediawiki.org and/or commons.wikimedia.org. See Commons_talk:CropTool#Unable_to_open_any_image_in_CropTool.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Today
Sat, Aug 24
Wed, Aug 21
Per RFC above.
Fri, Aug 9
Thu, Aug 8
Wed, Aug 7
Tue, Aug 6
Boldly closing this as declined, phetools OCR hasn't been up for a while (since 5 years?) and with the Grid engine shutdown of the tool, a revival seems unlikely.
Mon, Aug 5
Hmm, this doesn't appear to be a regression after a bit of digging, the associated code (includes/Hooks.php:227-231) seems to have been last changed 4 years ago.
Sat, Aug 3
In T217223#10040350, @Novem_Linguae wrote:Oh, and @Soda, you mentioned "Based on using the debug mode". Can you talk a bit more about this? If I want to also use debug mode to see what you see, any tips for me to enter debug mode? Is this a Visual Editor / DiscussionTools debug mode or something else?
The debug mode pops up when you use ?debug=true to any URL and then open the DiscussionTools dialog (to see the model changes, you need to select <show model> and <update on change>). It seems to be specific to VisualEditor/DiscussionTools.
I had similar results on a Pixel device that I own. Tho based on some percussive testing this seems like just a side effect of T217223. It seems like Android (and other Google-adjacent hardware) is missing some events that the VisualEditor tracks. In my experience, the reproduction case is as such:
Fri, Aug 2
Mon, Jul 29
That page was documenting the progress of the project with the same name.
Jul 21 2024
Triaging this as high, since this is adding quite a few old pages into the queue. @jsn.sherman could y'all take a look at the linked patch :)
In T370593#10000626, @Novem_Linguae wrote:Maybe it'd be a good idea to go back to the status quo ante behavior immediately. Then once that fire is out, we can take our time and potentially re-RFC the issue.
Jul 17 2024
+1 to this, a Wikisource yearinreview will be a good idea
Jul 15 2024
Jul 11 2024
The steps should approximately be:
- Create a page
- Delete said page
- Create a new page with the same name
- Check that PageTriage shows: "possible issues: previously deleted"
- Move said page to a new title
Jul 10 2024
In T363533#9968679, @Anujagrawal wrote:@Aklapper Check on patch failed and according to console it happened due to linting errors. What could i do?
Jul 9 2024
@Anujagrawal Can you link to your patch ?
Jul 7 2024
@Balajijagadesh Could you explain what the difference is ?
Jul 6 2024
@Balajijagadesh which Indic OCR service is this ?
Jul 5 2024
I don't think this can be reproduced since we moved hosts over the bookworm system (the logs are in the now shutdown system)
Jul 4 2024
I assume these have community consensus ?
Jul 2 2024
Hmm, that is weird, my patch does not touch afd_status and related variables in any way (in fact the patch should have no effect on the Javascript being loaded). I'll try to check this tmrw.
Is this ready for use in other extensions ?
Jul 1 2024
Thanking bots is allowed globally.
In T363250#9938034, @Pppery wrote:I have been ticking off done items from the checklists. The biggest delayer is Countervandalism-Network - nothing has been done there since August 2023, and about half of the post-creation tasks are pending only that. But I have no idea what to do to cause that to be done.
Jun 27 2024
In T363250#9928848, @Dcljr wrote:In T363250#9917916, @Soda wrote:In T363250#9917903, @Hakimi97 wrote:Hi, our community from Malay Wikisource is curious about normally who will be in charge of the configuration for the namespaces, logos and wordmarks? Will the configuration of the namespaces, logos and wordmarks done after all the wiki import task done, or the configuration could be setup at anytime?
Nobody in particular is in charge. Y'all will need to follow the general steps outlined in Requesting_wiki_configuration_changes
Are you saying these unchecked items in the task description have to be requested separately by the wiki community? I thought they were already "in the pipeline" to be done.
Jun 26 2024
In T366032#9928634, @Dzahn wrote:Hello @Soda,
this is still pending. Based on the tickets you linked that you work on, maybe you can ask @Samwalton9-WMF to be your sponsor? Do you normally chat with any WMF staff somewhere?
Let us know which teams and we can try to help.
Marking this as declined since you can now thank bots per this global RFC and subsequent implementation at 984288. :)
In T365071#9927056, @Jdlrobson wrote:@Novem_Linguae we are aiming to deploy dark mode to all wikis on 16th July. Do you need any help working out what to do for this ticket?
Jun 24 2024
In T363250#9917903, @Hakimi97 wrote:Hi, our community from Malay Wikisource is curious about normally who will be in charge of the configuration for the namespaces, logos and wordmarks? Will the configuration of the namespaces, logos and wordmarks done after all the wiki import task done, or the configuration could be setup at anytime?
Jun 21 2024
In T12347#9912216, @Quiddity wrote:Thank you for the reply and the draft @JJMC89 , much appreciated.
I will postpone including this in Tech News for now, in the hopes that someone can write/update the related documentation.
Jun 18 2024
Jun 17 2024
In T364690#9898721, @Vladis13 wrote:In T364690#9896615, @Soda wrote:In T364690#9896515, @Vladis13 wrote:And why, on each rendering, does the code recompile the index (mapping), although it does not change, and scan the pdf to Commons, which is not needed, since only text from the database is used? And besides the optimization problem, this leads to the discussed breakdown of the mass of pages.
As I said before the compilation does not happen on each render. It happens when a template transcluded/related to the page changes OR when the page is purged OR when the page is edited (basically ProofreadPage and the underlying parser treats the <pages /> tag like a series of templates and updates are triggered whenever mediawiki decides that the templates need updating).
Please answer my question above, and don't quibble with words. Re-compilations happens during rendering, or a couple of times less often when saves page/transclusions, there is almost no difference. Because when proofreading a book, there making a mass of edits/savings on tens and hundreds of pages of transclusions. And on each of these thousands of edits for each book, as you say, the code doing useless duplicates of re-compilations and https-requests to the Commons pdf, this leads to the discussed breakdown of the mass of pages of mass Wikisources.
Whereas in reality, the index page is usually edited only a few times, creating the desired listpages, nothing needs to be recompiled and everything will work without errors.Please answer my question above, why?
In T364690#9896515, @Vladis13 wrote:In T364690#9896511, @Soda wrote:In T364690#9896454, @Vladis13 wrote:In T364690#9895464, @Vladis13 wrote:In T364690#9798210, @Soda wrote:In T364690#9793607, @Vladis13 wrote:In T364690#9793548, @Uzume wrote:In T364690#9793303, @Vladis13 wrote:This shouldn't happen because the <pages/> mechanism works with text in Page and Index NS. Whereas the mediafile is in File NS. These are independent spaces.
But they aren't independent because the Index and Page pages depend on the File (and the Page pages also depend on the Index).
No, <pages/> only uses existing text in Page NS, file is absolutely not needed for this and is not used, why. Page and Index NS only use file during index page creation and visually assist users in proofreading. So, <pages/> should continue to display that text without breaking pages when the file is deleted.
That's incorrect, ProofreadPage depends on the File namespace to build the pagelist, figure out valid Page: namespace pages and determine the transclusion order of the pages.
That's what I said. The file is needed only at the modes of creating the pagelist (index) and proofreading.
The <pages /> tag should only take the text of pages from the local Wikisource database, according to a list of a pre-generated index. Why would it access an image file in the Commons repository?.. Sounds like nonsense. If this is indeed the case, then this is a major non-optimization of the code.
The index is computed based on the image file, or through manually linked pages as a fallback. I do not see why this is a "major non-optimization" or "nonsense".
You state that with EVERY reading of a page of a work by site readers, the index is re-generated, scanning the file in the Commons repository. This is a time-consuming and resource-intensive operation.
Then it should be like this:
- Only when saving the index page (Index NS) does the extension analyze the arguments of the <pagelist /> tag (which defines the mapping: pdf page number = book page number or literal label), creates an index (mapping, it’s short, banal "[{1: 'image'}, {2: 4}, {3: 5}, etc. according to the number of pdf pages]"), and is saves in the database. This is all.
- When a reader opens a page of a work, the <pages/> tag works only with database 1) takes the pages mapping from the database, takes the range of page numbers according to the arguments in the tag, 2) takes the text of the pages from the database, cuts out the sections specified in the arguments, renders html: gluing the texts of the pages, inserting between them the page numbers of the book with links to the pages of the Page NS, according to the mapping (index). This is all.
Compare the resource costs of generating an index from scratch for each read, and one only when saving the index page. I think this is obvious.
The recompilation happens on page save or link update on related pages, not on every render.
And why, on each rendering, does the code recompile the index (mapping), although it does not change, and scan the pdf to Commons, which is not needed, since only text from the database is used? And besides the optimization problem, this leads to the discussed breakdown of the mass of pages.
Jun 16 2024
In T364690#9896454, @Vladis13 wrote:In T364690#9895464, @Vladis13 wrote:In T364690#9798210, @Soda wrote:In T364690#9793607, @Vladis13 wrote:In T364690#9793548, @Uzume wrote:In T364690#9793303, @Vladis13 wrote:This shouldn't happen because the <pages/> mechanism works with text in Page and Index NS. Whereas the mediafile is in File NS. These are independent spaces.
But they aren't independent because the Index and Page pages depend on the File (and the Page pages also depend on the Index).
No, <pages/> only uses existing text in Page NS, file is absolutely not needed for this and is not used, why. Page and Index NS only use file during index page creation and visually assist users in proofreading. So, <pages/> should continue to display that text without breaking pages when the file is deleted.
That's incorrect, ProofreadPage depends on the File namespace to build the pagelist, figure out valid Page: namespace pages and determine the transclusion order of the pages.
That's what I said. The file is needed only at the modes of creating the pagelist (index) and proofreading.
The <pages /> tag should only take the text of pages from the local Wikisource database, according to a list of a pre-generated index. Why would it access an image file in the Commons repository?.. Sounds like nonsense. If this is indeed the case, then this is a major non-optimization of the code.
The index is computed based on the image file, or through manually linked pages as a fallback. I do not see why this is a "major non-optimization" or "nonsense".
You state that with EVERY reading of a page of a work by site readers, the index is re-generated, scanning the file in the Commons repository. This is a time-consuming and resource-intensive operation.
Then it should be like this:
- Only when saving the index page (Index NS) does the extension analyze the arguments of the <pagelist /> tag (which defines the mapping: pdf page number = book page number or literal label), creates an index (mapping, it’s short, banal "[{1: 'image'}, {2: 4}, {3: 5}, etc. according to the number of pdf pages]"), and is saves in the database. This is all.
- When a reader opens a page of a work, the <pages/> tag works only with database 1) takes the pages mapping from the database, takes the range of page numbers according to the arguments in the tag, 2) takes the text of the pages from the database, cuts out the sections specified in the arguments, renders html: gluing the texts of the pages, inserting between them the page numbers of the book with links to the pages of the Page NS, according to the mapping (index). This is all.
Compare the resource costs of generating an index from scratch for each read, and one only when saving the index page. I think this is obvious.
In T364690#9895441, @Vladis13 wrote:In T364690#9798244, @Uzume wrote:It seems like that patch, when merged might solve the issue with finding <pagelist/> usage when the File media cannot be properly processed
The patch has not been accepted so far. Am I wrong, or will the broken pages and their tracking never be fixed?
This request appears to be stalled, setting the status to reflect this task's current state. @SatyamMishra Given the comments above, I think having the community vote on an "autopatrolled" user group (and having an "only autopatrolled" user group) is probably a good next step.
Jun 14 2024
I haven't had time to look at Buster migration, but will do it within 15 July :)
Jun 13 2024
Jun 6 2024
Jun 5 2024
This should already be fixed in 1.43-wmf.8 which should be deployed on Thursday.
Jun 3 2024
Jun 2 2024
In T12347#9852076, @Sdkb wrote:We need to separate "people" out into readers and editors. For readers, the protection level has minor salience for information literacy purposes, as it can indicate e.g. how wary they should be of information on the page. For editors, the "can I edit?" question is primary, but the overall protection level still has some value for understanding the overall situation with the page (and can be accessed through the notice in the edit window or through the page information page).
Jun 1 2024
I've removed everything that was Wikisource-related :)
@Ankry I see the code snippet is still there in plwiki's common.js, is it still required ?
May 31 2024
In T211314#9849978, @Tacsipacsi wrote:
May 30 2024
May 29 2024
In T12347#9844517, @Soda wrote:
In T12347#9844450, @mwilliams wrote:Thanks for sharing @Soda! I'm seeing the same icon (Lock with nothing in it) for both semi-protected and fully protected. Is that to be expected as any update to the icon to visually communicate its protection level would be at a higher/ more specific presentation level?
In T12347#9841301, @RHo wrote:It would be extremely helpful if screenshots could be added (and/or a patchdemo created) to show what the proposed change is for design review. Curious if for example how the proposed change differs from the exisitng padlock style, position, and behaviour as the current protected enwiki pages like this one:
Sent the information. (in an email titled Re: Information for T366032 (Sohom Datta))
May 28 2024
May 27 2024
May 26 2024
May 24 2024
I will note Exporting Issues should be solved by the Wikisource extension which adds a download button on pages that can be downloaded.
Noting that implementing infinite scrolling will effectively result in a decline of T325607 since infinite scrolling is effectively unsupported by Google bot. :(
In T365806#9829770, @cscott wrote:These are proposals/help-wanted for now. The WMF annual planning process also deals better with discrete features/interventions, so if we can collaboratively hammer out the mechanics here it makes it easier to insert into planning to get resources allocated.
@Tgr, as mentioned above the Wikisource extension appears to already doing this server-side on a separate WMCS cluster. Also, the Collection extension was removed from Wikisource a while ago (see T358437).
Doesn't the Wikisource extension already account for this ?
@cscott Do you plan on working on these in the long term? Or are these just ideas?
May 23 2024
Pushing this to MediaWiki-Engineering to help figure out code review since (based on the Maintainers docs) they own the API component.
Looking at @Edtadros's screenshot, the divider in [ edit | edit source appears to be of insufficient contrast, is this a seperate bug or a something we missed ?
May 22 2024
https://gitlab.wikimedia.org/toolforge-repos/matchandsplit uses the configuration and appears to be working mostly fine.
My solution with Redis+Celery is to add a health check script that pings my worker(s), if the worker does not respond, Kubernetes kills the trainwreck and restarts the container.
I got nerd-sniped by this task and created a rough implementation for this API parameter.
May 20 2024
undefined should not show up there at all. This is a side-effect/symptom, not the actual issue.