In T319258#8349895, @ssastry wrote:Yes, any extension that deals with wikitext will need to implement functionality for Parsoid. See https://www.mediawiki.org/wiki/Parsoid/Extension_API#Parsoid_API_for_extensions ... We probably need a phab task for Pages that is a child task of T258838
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Oct 8 2023
Oct 8 2023
Ankry renamed T348396: Inconvenient widget order in Wikisource edit window in Page namespace from Inconvenient widget order in Wikisource edit window to Inconvenient widget order in Wikisource edit window in Page namespace.
Aug 15 2023
Aug 15 2023
Ankry renamed T344270: Cannot edit lexemes when Polish language set from Monobook users cannot edit lexems to Vector 2010 users cannot edit lexems.
Jun 24 2023
Jun 24 2023
Ankry updated the task description for T340365: Wikimedia mobile applications functions that require to login should not be available if mobile IP is blocked.
Feb 15 2023
Feb 15 2023
Jan 18 2023
Jan 18 2023
Ankry updated the task description for T327344: If scan is low, the edit summary field overlaps page footer in Page: namespace of Wikisource.
Jan 5 2023
Jan 5 2023
Ankry updated the task description for T326295: Edits to one page not shown in Special:RecentChanges in plwikisource.
Nov 30 2022
Nov 30 2022
Any decision what is the proper solution to remove <big> from Mediawiki-generated HTML5 code?
Oct 27 2022
Oct 27 2022
Oct 26 2022
Oct 26 2022
9 yers since it has been reported; very exciting pace of fixing this problem...
Oct 15 2022
Oct 15 2022
If there is no chance to fix the problem quickly in API, maybe a workaround in WS-Export may be introduced?
Oct 3 2022
Oct 3 2022
Aug 21 2022
Aug 21 2022
Ankry added a comment to T299521: PDF file has 0x0 image size in Commons after uploading a new version while the page number is correct.
In T299521#8170862, @JimKillock wrote:I'm getting a similar problem with this PDF:
- at Commons it is fine
- at la Wikisource it is 0x0px;
- at en Wikisource it is 0x0px;
- at en Wikipedia it is also 0x0px
(currently it is broke just on la.ws, as I reverted to an old version.)
May 1 2022
May 1 2022
Ankry added a comment to T192199: Proofread scan appearing tiny in wikisource, when creating or editing Page: pages.
In T192199#7891265, @Samwilson wrote:Since we've switched to OpenSeadragon for the image viewer, has this issue been resolved?
Jan 31 2022
Jan 31 2022
Ankry added a comment to T300563: Wikisource projects use different namespaces for page, so max width applying where it shouldn't.
- It was already suggested in T74525 to harmonize Page/Index namespace numbes across Wikisources
- The current number used can be retrieved from configuration using the wgProofreadPageNamespaceIds parameter
- The current list follows. It was extracted from the result of the script https://github.com/phil-el/phetools/blob/master/utils/gen_namespace.py
Please, remember that sourceswiki is also Wikisource (as "old" in the list below).
Jan 28 2022
Jan 28 2022
The problem appeared again today around 20:00 CET.
Maybe, it was a reason that there is much less number of files uploaded today than in previous days?
Special:Upload uploaded without any problem.
Jan 25 2022
Jan 25 2022
Ankry added a comment to T298417: Undeleted djvu files show incorrect metadata: 0x0 size, no page number info.
In T298417#7593773, @Ladsgroup wrote:This patch and running it would fix some of the issues but not all. For "filearchive" table fixes I need to find a separate way. In the meantime, any file that has been undeleted and now has issue, just list it here and I run the script on it.
Jan 21 2022
Jan 21 2022
Jan 19 2022
Jan 19 2022
Ankry renamed T299521: PDF file has 0x0 image size in Commons after uploading a new version while the page number is correct from PDF file has 0x0 image size in Commons after uploading a new version while page number is corect to PDF file has 0x0 image size in Commons after uploading a new version while the page number is correct.
Ankry renamed T299521: PDF file has 0x0 image size in Commons after uploading a new version while the page number is correct from PDF file has 0x0 image size in Commons after uploading a new version to PDF file has 0x0 image size in Commons after uploading a new version while page number is corect.
Ankry added a comment to T299521: PDF file has 0x0 image size in Commons after uploading a new version while the page number is correct.
Page number is properly set, so this problem seems to be different to T298417
Jan 9 2022
Jan 9 2022
Ankry added a comment to T298417: Undeleted djvu files show incorrect metadata: 0x0 size, no page number info.
In T298417#7594875, @Ladsgroup wrote:Don't worry on that, just make it top version and then let me know to run the script (until I make the patch merged and deployed)
Jan 3 2022
Jan 3 2022
Ankry added a comment to T298417: Undeleted djvu files show incorrect metadata: 0x0 size, no page number info.
In T298417#7593773, @Ladsgroup wrote:This patch and running it would fix some of the issues but not all. For "filearchive" table fixes I need to find a separate way. In the meantime, any file that has been undeleted and now has issue, just list it here and I run the script on it.
Jan 1 2022
Jan 1 2022
Ankry added a comment to T298417: Undeleted djvu files show incorrect metadata: 0x0 size, no page number info.
An attempt to reupload (even the failed one) restores the metadata in Commons:
https://commons.wikimedia.org/wiki/File:Skibinski_pamietnik0001.djvu
But this does not restore the metadata in Wikisource:
https://pl.wikisource.org/wiki/Plik:Skibinski_pamietnik0001.djvu
so cannot be used as an ugly workaround
Ankry added a comment to T298417: Undeleted djvu files show incorrect metadata: 0x0 size, no page number info.
In T298417#7592558, @Umherirrender wrote:In T298417#7592371, @Ankry wrote:Same problem with unhiding a file version that was hidden in August 2021:
https://commons.wikimedia.org/wiki/File:PL_Miriam_-_U_poet%C3%B3w.djvuThis is affected by the missing split of big metadata for the filehistory (oldimage table).
The original task description is affected by the missing split of big metadata for the file archive (filearchive table)
The work was done as part of T275268, but the refreshImageMetadata.php only running for the current file versions
Ankry updated the task description for T298417: Undeleted djvu files show incorrect metadata: 0x0 size, no page number info.
Ankry added a comment to T298417: Undeleted djvu files show incorrect metadata: 0x0 size, no page number info.
Same problem with unhiding a file version that was hidden in August 2021:
https://commons.wikimedia.org/wiki/File:PL_Miriam_-_U_poet%C3%B3w.djvu
Ankry added a comment to T298417: Undeleted djvu files show incorrect metadata: 0x0 size, no page number info.
One more example:
https://commons.wikimedia.org/wiki/File:PL_Kieszonkowy_s%C5%82ownik_j%C4%99zyk%C3%B3w_%C5%82aci%C5%84skiego_i_polskiego._Cz._1,_S%C5%82ownik_%C5%82aci%C5%84sko-polski.djvu
(this one has been deleted in 2018)
Dec 9 2021
Dec 9 2021
In T297339#7558451, @Inductiveload wrote:Quick user-side fix for the non-toolbar vertical layout appears to be some CSS:
#prp-page-image-openseadragon-vertical { height: 100%; }
Ankry added projects to T297339: Page scan is not displayed when 2010 toolbar is disabled: ProofreadPage, Regression.
Ankry updated the task description for T297338: Switching to horizontal mode in ProofreadPage leaves the edit window narrow.
Nov 24 2021
Nov 24 2021
Nov 22 2021
Nov 22 2021
In T296033#7521448, @Inductiveload wrote:@Ankry OSD redeployed today along with a backport for this issue in the evening window (the first after the .9 deployment). Could you check and close if OK?
not working or the fix not deployed yet?
Nov 19 2021
Nov 19 2021
Works in production.
May it be related to moving the zooming tool outside of the "Proofread tools" submenu? It seems to be initialized regardless of the toolbar setting.
People also report that the tool zooming is less granular now (single zooming is much higher than it was previously). But this needs a separate bug.
Nov 18 2021
Nov 18 2021
Ankry added a project to T296033: Disabling toolbar no longer works in Page namespace: ProofreadPage.
It seems rthat this ProofredPage change may be responsible for unintended loading of wikiEditor:
https://github.com/wikimedia/mediawiki-extensions-ProofreadPage/commit/645dfcc92e5e41490ab724e79f0627aa928ca2ba
Can someone verify this?
Thanks to @PeterBowman for finding this.
In T296033#7515221, @MusikAnimal wrote:Ankry, Do you have a Global Preference set for this? Check Specjalna:Globalne preferencje. This may be related to T296028: Unable to set a local override for some Global Preferences
No. The global preference for toolbar is also disabled.
Well that's a relief (for me). Upon further inspection, this doesn't appear to be related to the work we've recently done around Global Preferences. I can also confirm it appears to be unique to Wikisource, so I don't think it's an issue with preferences in general.
The problem was reported to me by other users, who also want the toolbar to be disabled as it is highly resource consuming
In T296033#7515187, @MusikAnimal wrote:@Ankry Do you have a Global Preference set for this? Check Specjalna:Globalne preferencje. This may be related to T296028: Unable to set a local override for some Global Preferences
Ankry added a comment to T215558: Proofread Page extension on Wikisource is displaying wrong pages; purge on Commons file fails.
In T215558#7511187, @Xover wrote:In T215558#7510911, @Legoktm wrote:That said...the real problem is clearly that MediaWiki or Thumbor or Varnish is not able to purge all the thumbnails. If someone has an example from the past 7 days it might be possible to look through the logs to get an idea of where the failure is happening (or at least rule out some stuff).
I don't have any files where the thumbnails are currently wrong (maybe someone else subscribed here has?), but the file mentioned in the description returned a failure when purging through the API earlier today (it succeeds now); and I just tested with the file from T206190 and got a failure. Presuming we don't have stale noise hanging around from older operations tripping up the API, whatever fails should have generated a log message somewhere for these.
Nov 8 2021
Nov 8 2021
Ankry added a comment to T192866: Some DjVu files have too much metadata to fit in their database column.
In T192866#7489510, @TheDJ wrote:From memory, the Xml is needed to figure out the w x h of each page and how many pages there are... and to get the text of each page.
Oct 31 2021
Oct 31 2021
Ankry added a comment to T192866: Some DjVu files have too much metadata to fit in their database column.
In T192866#7470114, @Xover wrote:c:File:A_Latin_Dictionary_(1984).djvu shows up with the right dimensions, thumbnails, etc.
s:File:A Latin Dictionary (1984).djvu shows up with 0x0 dimensions, no thumbs, etc.
Interesting. I've just reuploaded this file (for unrelated reasons) and now the previous revision is showing up on Commons with 0x0 pixel dimensions (but still 245MB file size). The current revision now shows up fine on Commons (as the previous did at the time it was uploaded) with dimensions and size, but when viewed from enWS it's broken (0x0) and PRP still chokes on it.
Oct 14 2021
Oct 14 2021
This seems to be fixed already by @Candalua . Am I wrong?
Whatever the underlying pronlem was, the file renders now.
Sep 25 2021
Sep 25 2021
Just FYI: this is not a newly uploaded file, but a new version overwriting the old one (and the old version has been deleted due to copyvio)
Sep 24 2021
Sep 24 2021
Fixed using thump.php thumbnail regeneration
Sep 23 2021
Sep 23 2021
Sep 21 2021
Sep 21 2021
Jul 25 2021
Jul 25 2021
Ankry added a comment to T287331: Old page rendering is presented to anonymous users after purge/nulledit by a logged in user.
Can this be a side-effect of FlaggedRevs?
Jul 24 2021
Jul 24 2021
Ankry added a comment to T287331: Old page rendering is presented to anonymous users after purge/nulledit by a logged in user.
Well, this error appears quite often, almost on any non-tiny score, in most cases immediately after request, and often multiple times if retrying.
In T287165#7233544, @Legoktm wrote:@Inductiveload this looks fixed to me with lilypond 2.22.0 now, can you confirm?
In T257066#7233536, @Legoktm wrote:https://test.wikipedia.org/wiki/Score/plwikisource/3 isn't working for other reasons besides #UP I think, so that probably merits a dedicated task?
Jul 22 2021
Jul 22 2021
In T257066#7229715, @Inductiveload wrote:Adding a cache-busting "." to the title of https://en.wikisource.org/wiki/Abide_with_Me_(Illustrated_Victorian_Songbook) causes a parse failure:
First testing results:
Jul 17 2021
Jul 17 2021
If the thumbnail generation cannot be requested asynchronously, to avoid delay in presenting current page HTML code to user (and utilize the time when the page is being downloaded / rendered by the browser for thumbnail generation), then (IMO) it is better to request the next thumbnail generation from some javascript code which would be invoked after the page is already displayed in the browser. This is the way that current pl.ws/it.ws gadgets seem to utilize.
The main goal here is to perform server-side page thumbnail generation in advance. If this can be made without preloading, it is OK. I am not sure if prefetch would provide this.
Thumbnail generation process has been identified to be the most time-consuming part of the "next page" loading process. So making the next thumbnail ready server-side is the main goal.
Jul 12 2021
Jul 12 2021
In T257066#7206936, @Ankry wrote:In T257066#7206899, @Legoktm wrote:In T257066#7206860, @Ankry wrote:I used Special:ExpandTemplates to get the underlying generated <score> tags for that page and saved them on https://test.wikipedia.org/wiki/Score/plwikisource where it looks like they all work.
Well, it is not eactly the final code generated by LUA, but, I think, the final one would not need more features.
In T257066#7206899, @Legoktm wrote:In T257066#7206860, @Ankry wrote:I used Special:ExpandTemplates to get the underlying generated <score> tags for that page and saved them on https://test.wikipedia.org/wiki/Score/plwikisource where it looks like they all work.
https://pl.wikisource.org/wiki/Pro%C5%9Bba_dziewcz%C4%99cia
Transcluded using ProofreadPage and LUA from
pages:
https://pl.wikisource.org/wiki/Strona:Pro%C5%9Bba_dziewcz%C4%99cia.djvu/3
https://pl.wikisource.org/wiki/Strona:Pro%C5%9Bba_dziewcz%C4%99cia.djvu/4
https://pl.wikisource.org/wiki/Strona:Pro%C5%9Bba_dziewcz%C4%99cia.djvu/5
https://pl.wikisource.org/wiki/Strona:Pro%C5%9Bba_dziewcz%C4%99cia.djvu/6
https://pl.wikisource.org/wiki/Strona:Pro%C5%9Bba_dziewcz%C4%99cia.djvu/7
LUA modules used are:
https://pl.wikisource.org/wiki/Modu%C5%82:Mscore
https://pl.wikisource.org/wiki/Modu%C5%82:Mscore_resizable
+ few templates
Hard to do. It is a piece of LUA and requires proofreage namespaces. It would need not trivial porting to test there.
It works through {{#tag:score|...}} and LUA-generated code.
We are using some tools in plwikisource that require the raw mode. The tools are intended to choose among various width scores (when rescaling a window) and for merging multiple scores. Will they work? The most "complex" lilypond feature they need is to define and use own variables (as \commands).
We are ready to test this, if possible.
Jun 19 2021
Jun 19 2021
Ankry renamed T206190: Outdated thumbnails for djvu file on Commons cannot be purged and do not update from Outdated thumbnail for djvu file on Commons cannot be purged and does not update to Outdated thumbnails for djvu file on Commons cannot be purged and do not update.
Ankry added a comment to T206190: Outdated thumbnails for djvu file on Commons cannot be purged and do not update.
Just FYI: currently, we are replacing ProofreadPage generated images with images of different pixel size altering the page content using MediaWiki:Common.js (for affected pages). But any suggestion of less ugly workaround is welcome.
Ankry added a comment to T206190: Outdated thumbnails for djvu file on Commons cannot be purged and do not update.
Problem not observed for over a year, but it appeared again recently.
See:
https://upload.wikimedia.org/wikipedia/commons/thumb/a/a7/Karol_May_-_Old_Surehand_06.djvu/page94-878px-Karol_May_-_Old_Surehand_06.djvu.jpg
and compare with eg.
https://upload.wikimedia.org/wikipedia/commons/thumb/a/a7/Karol_May_-_Old_Surehand_06.djvu/page94-879px-Karol_May_-_Old_Surehand_06.djvu.jpg
(they are thumbnails of different pages while related to the same page number (94))
Jun 12 2021
Jun 12 2021
Ankry added a comment to T284853: Echo notification points to incorrect anchor (some <pre>/<nowiki> text within that section which includes ==text==).
@Aklapper This is not anout mail notifications. This is about on-wiki notifications (under the bell icon)
May 2 2021
May 2 2021
Ankry added a project to T279773: Proofread status info is displayed in incorrect language: Regression.
The problem appeared again in 3 diffs related to edits of another, relatively new user:
https://pl.wikisource.org/w/index.php?title=Strona:PL_Gloger-Encyklopedja_staropolska_ilustrowana_T.1_154a.jpg&diff=prev&oldid=2763887
https://pl.wikisource.org/w/index.php?title=Strona:PL_Gloger-Encyklopedja_staropolska_ilustrowana_T.1_155.jpg&diff=2763904&oldid=2595080
https://pl.wikisource.org/w/index.php?title=Strona:PL_Gloger-Encyklopedja_staropolska_ilustrowana_T.1_156.jpg&diff=2763920&oldid=2595081
Apr 28 2021
Apr 28 2021
Apr 23 2021
Apr 23 2021
Whatever the reason was, the problem disappeared.
Apr 9 2021
Apr 9 2021
Mar 27 2021
Mar 27 2021
After removing this content
https://pl.wikipedia.org/w/index.php?title=Wikipedysta:ActisTestantibus/brudnopis&oldid=62764947
form this thread:
https://pl.wikipedia.org/w/index.php?title=W%C4%85tek:W5pkzjvcn2vxv8pu&topic_postId=w5pkzjvcn6u03co2&topic_revId=w5qd9m9v2q9ft3yi&action=single-view
problem in the help page disappeared.
Mar 23 2021
Mar 23 2021
Feb 27 2021
Feb 27 2021
Ankry added a comment to T275958: Enable interlanguage links from multilingual Wikisource to other Wikisources.
Generally they probably should not have such pages:
- in the main namespace, each page that should be linked to Wikidata constitutes a separate edition. They should be linked in Wikidata using https://www.wikidata.org/wiki/Wikidata:WikiProject_Books
- in the Author namespace it is possible that there are few Author pages providing the Author name in various languages but this should be resolved internally by creating a multilingual author page in such cases and I do not think we should care of this problem
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL