User Details
- User Since
- Oct 7 2014, 5:56 AM (541 w, 7 h)
- Availability
- Available
- IRC Nick
- Tpt
- LDAP User
- Tpt
- MediaWiki User
- Tpt [ Global Accounts ]
Jan 6 2025
@hubaishan Thank you! A workaround is to write {{#if:{{{فقط الفصل|}}}|onlysection={{{فقط الفصل}}}}} instead of onlysection={{{فقط الفصل|}}} to only set the onlysection parameter only if فقط الفصل is set
Thank you for raising this! Currently all <pages> parameters are considered to be set when their value is the empty string. The suggested change would change the behavior only for the onlysection parameter. Hence, I am a bit reluctant to apply it. What would be an intended use case of the change?
I think we can solve it. Thanks for the reminder!
Jan 4 2025
One can use https://manual.calibre-ebook.com/generated/en/ebook-convert.html to generate markdown files from ePubs. It's what ws-export uses internally for PDF/RTF/...
Dec 31 2024
I have rebooted the instance, service seems to be properly served now.
Jul 15 2024
Sadly the assumption that the order in the file is the order of transclusion is deeply ingrained into ProofreadPage. Changing that is going to be quite hard. I am afraid it won't be done anytime soon except if someone step up to do it.
Mar 17 2024
I wasn't able to get one line per wiki, but https://wsstats.toolforge.org/stats/all/alltime exists now which gives a overview of all wikisources.
Mar 15 2024
@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)?
Jan 18 2024
Jan 5 2024
I have uploaded a change that converts the <table> to a <ul>. @Poslovitch is it better? If you prefer I can switch to a <div> instead: https://gerrit.wikimedia.org/r/987944
Dec 23 2023
@Samwilson Thank you so much for investigating this problem!
Dec 22 2023
This is strange. The file is present on the server but not served anymore by Apache for I dont know what reason.
Dec 18 2023
The controller loop that waits for the book to be generated. Maybe it should do something better.
Dec 17 2023
@Samwilson if you think you won't manage to do it in the next few months, I think I can take some time to work on it.
Dec 3 2023
+1 to @Tacsipacsi. It's probably the best way to go. Would someone have time to do it? Help would very much welcomed
Aug 19 2023
I am not actively maintaining the extension. I never took the time to try to rewrite it properly. I am fine with undeploying it. Some consultation of the users (frwikisource...) might be nice to avoid a backslash.
Mar 18 2023
Idea: it might be nice to use Terraform for the migration to ease future migrations (Bookworm...)
Mar 17 2023
Feb 27 2023
simplewd has been deleted
Feb 16 2023
@Billinghurst @Xover Sorry for that. I have just pushed a fix for review: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/LabeledSectionTransclusion/+/889867/
Feb 11 2023
Jan 23 2023
@Soda Thank you for reaching out with this problem and moving forward with it.
Nov 1 2022
This bug seems to have been fixed upstream in ImageMagick https://github.com/ImageMagick/ImageMagick/issues/2070
We should upgrade it in WSexport servers
Oct 31 2022
@Zdzislaw I have made some refactoring to properly cleanup the way the index quality stats are updated. It is likely it has fixed this bug in the process.
Oct 27 2022
After some investigation, it seems this bug has been introduced by the migration to Parsoid. It's likely that Parsoid fully parses wikitext from custom MW tags like <pages>, including references, before including them in Parsoid output. Adding native support of <pages> to Parsoid might fix this problem (or not, not sure...).
Oct 15 2022
It sounds like one of the main issues with doing that might be on talk pages, where multiple different Index pages might be linked (for examples etc.), but actually I think this is highlighting an existing problem with how we handle linking to multiple sources. For example, a top-level page for a work might want to display the tables of contents from multiple volumes with something like this (where each volume has its ToC on page 5):
Sep 22 2022
Fixed on Wikisources
Sep 21 2022
Quick fix to add to Common.css:
.pr_quality { width: 100px; }
Jul 2 2022
May 29 2022
Indeed, this bug is related to c1f80efe05349cc39cb82dc9347b0a7699b11dfd (T304303): the live preview feature relies on the JS API allowing to fetch the current content of the editing area. To fix T183950 we dropped the hack inside of ProofreadPage that provides not only the page body but also the proofreading level and the page header/footer as page content. So, after this change, only the page body is fed to the live preview feature, hence the bug. A possible solution might be to add back the "complete page content" hack inside of ProofreadPage but some signficant work would be required to make features like find/replace work with this hack.
May 26 2022
I have written an implementation draft: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikisource/+/793867
May 9 2022
Mar 27 2022
Feb 14 2022
A fix has just been merged https://github.com/wikimedia/ws-export/pull/397 with a nicer follow up https://github.com/wikimedia/ws-export/pull/398
Jan 31 2022
Jan 13 2022
rel=prefetch has been added targetting the previous and next pages to speed up bulk proofreading according to T230689
Jan 7 2022
@Xover Sadly there is not hope for it to be pushed today except if someone is managing to follow the emergency deployment process: https://wikitech.wikimedia.org/wiki/Deployments/Emergencies
High priority: breaks a part of the basic Wikisource proofreading workflow.
Jan 6 2022
@Inductiveload Thank you!
I wrote a change that should fix the bug https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ProofreadPage/+/751946/
Jan 4 2022
The bug happend again on the new disk with the "exhibitorsherald2*" files. I removed them to put the tool back on. We should maybe prevent files >1GB to be downloaded and processed.
Dec 8 2021
Dec 1 2021
@Xover Thank you so much for having found this issue. It was under my nose all this time.
Nov 24 2021
@Mahir256 The change I wrote is in fact buggy. It's looking for a field named "toc" and not a field which data field is "toc". I'm writing a fix right now. Sorry for that.
Nov 23 2021
@Soda do you have a HiDPI screen? If it's the case, I believe modern browsers will download and use the bigger image that is provided by the srcset attribute before the initialization of Openseadragon. Then Openseadragon is initialized and use the regular size image. It's what happens with my 4K screen configured with 2x scaling.
Nov 21 2021
Sorry, I made a confusion between two different numerical systems: the ICU "beng" numerals are defined as the 10 digits "০১২৩৪৫৬৭৮৯" and, so, are not using base 16 as the currency numerals requested by this task. The base 10 numerical system is properly implemented and available now, the base 16 numerals are not yet availlable and not provided by ICU.
@Inductiveload I believe @Bodhisattwa says that the "beng" option is not visible in the pagelist editing widget.
Nov 19 2021
@Thadguidry @BenAtOlive It's a great idea to move the conversation somewhere else. Oxigraph has a discussion space and a Gitter channel.
@BenAtOlive If I understand correctly, you are asking if Oxigraph can be used to build a distributed SPARQL database with reader nodes and writer nodes? Its definitely possible to reuse Oxigraph components for that. For example I am currently moving the SPARQL parser out of Oxigraph and I plan to add general SPARQL query optimizations to it. However, building a query evaluator against a distributed storage where data are not in the same machine as the one executing (or at least scheduling) the query is a quite different task as building a query executor against a single node database. Access latencies are easily an order of magnitude higher with a remote store and it changes quite a lot of tradeoffs. So, yes for making the part of Oxigraph that are easy to reuse reusable but sadly I am not sure that naively spliting the query evaluator out of Oxigraph would provide a good query evaluator on top of a distributed storage.
Nov 18 2021
The change fixing this issue is now merged.
Nov 16 2021
Nov 15 2021
It's a great idea! I just believe P2860 (cites work) should be removed from the list. It's definitely not a classifying property.
Oct 3 2021
It is now fixed. There was some broken job data in the file system because of the full disk problem. I have opened T292365 to prevent it to happen again.
It's because the disk is currently full. I have removed a few huge books from the job queue and rebooted the server. However it does not seems to be enough to bring the website back.
Sep 17 2021
@Ladsgroup Thank you! So what would you think about MCR for storing the "main" data and some change tags as "secondary" data for queryability and recent changes filtering? This way we would get the best of both worlds.
Sep 15 2021
Thank you @Tgr and @Ladsgroup for your feedbacks!
Sep 14 2021
Sep 13 2021
@Inductiveload Great question! We might start now. Maybe with oldwikisource?
Sep 8 2021
Sep 2 2021
@Aklapper Thank you! Most of Wikisource now use that is an improved version of Mediawiki:Proofreadpage_index_attributes. MediaWiki:Proofreadpage_index_data_config is defined in the Hebrew Wikisource.
Aug 31 2021
@Thadguidry Great! Thank you!
@Thadguidry Hi! It's a great idea to improve the roadmap. Thank you for pushing me to do that! I have updated the GitHub issues and milestones and added a link to them in the README:
Each milestone should now have a short description and a set of linked issues. Most of the issues have been connected to a milestones.
I am a bit afraid of adding a ROADMAP file to the repository because it is yet another source of truth to maintain.
To also keep a single source of truth I made the choice to not expand the milestone description too much and keep the detailed discussions inside of issues. Here is [one about the storage backend and Sled]( https://github.com/oxigraph/oxigraph
/milestones?direction=desc&sort=completeness&state=open). However, the milestone+connected issues descriptions should allow to make sense of the roadmap. Feel free to ping me if you believe it's not clear enough.
Aug 26 2021
Thank you @So9q for opening this task!
Aug 25 2021
I'm working on a fix. Should be ready soon. Sorry for the troubles.
Aug 12 2021
Fixed and deployed.
Aug 7 2021
Sorry, I should not have closed this issue. The change that should fix this problem is not merged yet: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ProofreadPage/+/704564
So, it makes sense that the problem does not seem solved on Wikisource.
Aug 5 2021
How widespread is the impact of this bug remaining unfixed? If it's a nitch use and we can fix it with a backport in the short term then I wouldn't roll back. On the other hand, if this is causing some fallout elsewhere or triggering major production breakage then definitely roll back.
Aug 4 2021
Yes. To make it work properly "data": "toc" should be added to the relevant field in Mediawiki:Proofreadpage_index_data_config.
Jul 31 2021
@DannyS712 Thank you! I have understood why e.g. https://phabricator.wikimedia.org/diffusion/EPRP/browse/master/includes/Pagination/Pagination.php$25 is not flagged by these sniffs. It's because abstract methods are not covered by the lint: https://github.com/wikimedia/mediawiki-tools-codesniffer/blob/5f813f727ee47d5c90981b44e82f0c5a0263e933/MediaWiki/Sniffs/Commenting/FunctionCommentSniff.php#L198
Jul 19 2021
Thank you @Ankry, @Xover @Inductiveload! So I guess rel="preload" seems the way to go for the next page image. What about using rel="prefetch" for the previous one? This way, it gets a good chance to be loaded too but with less priority. What do you think about it?
Jul 17 2021
@Ankry Thank you! So, I guess that the main goal is to make sure that the image thumbnail is already generated when a Page: page is displayed.
Jul 13 2021
Jun 30 2021
But aiui the granularity would be per-project and not per-index. How would a project start experimenting with this or avoid the need for a big bang migration? Use two toc fields in the index, one for the traditional way and one for a "Wikidata-based toc"? That would necessitate PRP differentiate between "present" and "non-empty" for the index data field tagged with "data": "toc", I think. That sounds a little more complicated, but is perhaps not too much so?
Jun 29 2021
Jun 8 2021
The "Source" tab is currently inserted using javascript ("modules/article/ext.proofreadpage.article.js"). It might be possible to use the same trick for Minerva. But migrating everything to PHP would be nicer.
@Tpt Is there a technical reason for this?
May 22 2021
Done and deployed
Sorry for stepping in. A maybe relevant task when designing a new zooming system: T43614
Mar 27 2021
After thinking a little bit (and asking my wife who does not contribute to Wikisource), I have a feeling using an indicator is maybe not highlighting enough the proofreading level information: it's the first thing people are often looking for if they go to a page: page. But I am not an UX design expert so maybe an indicator is good enough.
Thank you for pushing this. I am a bit afraid it might create a backlash with some contributors feeling that the proofreading level is not highlighted enough. It might be nice to start a discussion on the biggest Wikisource communities. A first step is maybe to move the quality level from the <pages> tag and in the Index namespaces to an indicator.
This is presumably very nearly T239033, since if the extension can add a "Source" link for a mainspace page user of <pages/>, it can do it in any other namespace?
@Inductiveload Yes, I guess it should be also done in onSkinTemplateNavigation. The tricky part is that the "source" link is not known from the current page title but from the parser output, and onSkinTemplateNavigation do not have access to the parser output. It's why I have not done the migration to server side yet. There is maybe a good solution, I have not taken much time to look for an alternative yet.