Page MenuHomePhabricator

Xover
User

Projects

User does not belong to any projects.

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Friday

  • Clear sailing ahead.

User Details

User Since
Apr 16 2017, 6:32 PM (154 w, 2 d)
Availability
Available
LDAP User
Unknown
MediaWiki User
Xover [ Global Accounts ]

Recent Activity

Tue, Mar 24

Xover added a comment to T244657: Visual Editor moves ProofreadPage haeader / footer into page text field, duplicating them.

Hey @ifried is this a challenge a lot of people are encountering?

Tue, Mar 24, 4:28 PM · Editing-team, Community-Tech, VisualEditor, ProofreadPage

Feb 18 2020

Xover added a comment to T245549: Cleanup and document code dealing with incomplete follow.

Semantically the incomplete ref is part of the list, it just shouldn't get the backlink and marker. I don't think the <p> wrapper is important (in fact, it might be better without: cf. T49544). I think in general the short summary for these refs is that they 1) should be at the top of the list, and 2) should not have a backlink and marker. Everything else is implementation detail and practical considerations.

Feb 18 2020, 8:04 PM · Patch-For-Review, Technical-Debt, WMDE-QWERTY-Team, Book-Referencing, Cite
Xover added a comment to T49544: <references/> list item must not wrap the text in <span>.

[ Apparently I didn't post this at some point back in January when I wrote it ]

Feb 18 2020, 8:03 PM · Wikisource, Patch-For-Review, Technical-Debt, Cite

Feb 14 2020

Xover added a comment to T245154: Edit conflicts in the page namspace show unintended newlines in footer diff.

@Tpt rtrim() removes trailing whitespace only, so this shouldn't affect leading newlines in the body of the page, should it?

Feb 14 2020, 6:50 PM · MW-1.35-notes (1.35.0-wmf.20; 2020-02-18), WMDE-QWERTY-Sprint-2020-02-04, TCB-Team, ProofreadPage, Two-Column-Edit-Conflict-Merge
Xover added a comment to T241889: Previewing a Page: page appends unwanted newlines to each section.

@WMDE-Fisch Doesn't this just hide the problem? These newlines are coming from somewhere, and I can't think of a valid reason for them, so the root cause really should be fixed imo.

Feb 14 2020, 1:12 PM · Regression, ProofreadPage, Wikisource
Xover closed T242422: Proofreadpage attempts to use images with non-integer pixel size as Resolved.

Since this seems to be essentially a dup of T242517 which was fixed by reverting; the part of the change that triggered this task was not an intended change in platform behaviour (it was an unintended side-effect of phan cleanup); and all the specific cases reported in this task have been resolved… I'm going to go ahead and "boldly" close this as resolved. @Ankry Please reopen if you disagree.

Feb 14 2020, 6:38 AM · ProofreadPage
Xover added a comment to T245154: Edit conflicts in the page namspace show unintended newlines in footer diff.

Could this be related to T241889?

Feb 14 2020, 6:23 AM · MW-1.35-notes (1.35.0-wmf.20; 2020-02-18), WMDE-QWERTY-Sprint-2020-02-04, TCB-Team, ProofreadPage, Two-Column-Edit-Conflict-Merge

Feb 12 2020

Xover added a comment to T162520: IA Upload unable to convert a JPEG2000 to JPEG.

Yes, I just retried handbookofnature00coms_0 and that is an instance of T215647:

Feb 12 2020, 5:02 PM · IA Upload
Xover added a comment to T162520: IA Upload unable to convert a JPEG2000 to JPEG.

Hmm. I grabbed the JP2s and ran gm on them, and the issue seems to be that these files, by virtue of being a pretty ridiculous resolution (6851x10000), exceeds a hard-coded limit in—in my case—the Jasper library that gm uses for JPEG-2000 support. I believe gm can be linked against different libraries for this (and the particular problem is a Jasper thing) which probably explains some variability in symptoms: different distributions will have linked different underlying libraries, and it may change with OS updates. I think this specific scan is best considered a pathological case.

Feb 12 2020, 7:27 AM · IA Upload

Feb 11 2020

Xover added a comment to T204417: IA Upload not uploading files.

Apt-ark uploaded this file to Commons manually (as File:Arkansas_Constitution_1874_(published_1913).pdf) so this task can probably be closed as stale now.

Feb 11 2020, 4:28 PM · IA Upload
Xover added a comment to T214798: Files uploaded but Commons page failed to generate...

The logs (and other files) get deleted after some time so this now seems rather hard to debug (pro tip: upload the logs as attachments, or excerpt the relevant parts in a comment, to preserve them).

Feb 11 2020, 4:22 PM · IA Upload
Xover added a comment to T222756: Upload of monumentistorici01bind failed.

This is a duplicate of T215647.

Feb 11 2020, 1:42 PM · IA Upload, Internet-Archive
Xover added a comment to T192735: IA-upload log throws "Command not found: "djvm -c "" error message.

This is almost certainly the same issue as T215647 (but that task has more log data).

Feb 11 2020, 12:18 PM · Internet-Archive, IA Upload

Feb 7 2020

Xover added a comment to T240858: Clean up implementation for "follow" cases.

@awight It seems all wikis were rolled back to wmf.16 (including the l10n cache) for other reasons, so we're now back to the status quo and <ref follow="foo"> works as normal again. As I understand it they haven't decided yet whether next week's deploy will be retrying wmf.18 or moving on to wmf.19, but from my (very limited) understanding we should not run into this particular issue again either way.

Feb 7 2020, 6:19 PM · WMDE-QWERTY-Sprint-2020-02-04, MW-1.35-notes (1.35.0-wmf.19; 2020-02-11), WMDE-QWERTY-Sprint-2020-01-21, WMDE-QWERTY-Sprint-2020-01-08, User-notice, Patch-For-Review, Technical-Debt, Book-Referencing, Cite, WMDE-QWERTY-Sprint-2019-12-11
Xover added a comment to T240858: Clean up implementation for "follow" cases.

@awight Ok, so the summary seems to be: when the next planned "full scap sync" happens on Tuesday the l10n cache CDBs will get rebuilt with the correct messages, and either on Tuesday or Wednesday—depending on in which phase the caches get pushed out—the missing message key will become available on all the Group 1 wikis and this problem will go away. Is that roughly correct?

Feb 7 2020, 4:31 PM · WMDE-QWERTY-Sprint-2020-02-04, MW-1.35-notes (1.35.0-wmf.19; 2020-02-11), WMDE-QWERTY-Sprint-2020-01-21, WMDE-QWERTY-Sprint-2020-01-08, User-notice, Patch-For-Review, Technical-Debt, Book-Referencing, Cite, WMDE-QWERTY-Sprint-2019-12-11
Xover added a comment to T240858: Clean up implementation for "follow" cases.

@awight Per Nemo above (and on IRC) there is some chaos surrounding this week's deploy train, and issues related to that which are keeping the key people busy. It sounds plausible that this and those issues may be related; but I have no details on what's going on beyond the task Nemo linked above (T233866, <s>which just looks like the deployment tracker to me</s> Nope, I see it's been updated with significant and relevant breakage.).

Feb 7 2020, 7:57 AM · WMDE-QWERTY-Sprint-2020-02-04, MW-1.35-notes (1.35.0-wmf.19; 2020-02-11), WMDE-QWERTY-Sprint-2020-01-21, WMDE-QWERTY-Sprint-2020-01-08, User-notice, Patch-For-Review, Technical-Debt, Book-Referencing, Cite, WMDE-QWERTY-Sprint-2019-12-11

Feb 6 2020

Xover added a comment to T240858: Clean up implementation for "follow" cases.

Just for completeness: I've verified that the problem occurs on plWS as well as enWS.

Feb 6 2020, 10:49 PM · WMDE-QWERTY-Sprint-2020-02-04, MW-1.35-notes (1.35.0-wmf.19; 2020-02-11), WMDE-QWERTY-Sprint-2020-01-21, WMDE-QWERTY-Sprint-2020-01-08, User-notice, Patch-For-Review, Technical-Debt, Book-Referencing, Cite, WMDE-QWERTY-Sprint-2019-12-11
Xover updated subscribers of T240858: Clean up implementation for "follow" cases.

@Billinghurst I'm told there are other ongoing issues that may make getting the right eyes on this problem difficult with any urgency (cf. Nemo's message above). But as I recall you're a global interface admin: your thoughts on requesting the global interface admins on meta to mass add this interface message on all the affected projects? Details of what's needed in Thiemo's message above. We'd need to also remove it again once whatever is causing this is fixed, which I'm not sure whether the interface admin bit is sufficient for.

Feb 6 2020, 9:30 PM · WMDE-QWERTY-Sprint-2020-02-04, MW-1.35-notes (1.35.0-wmf.19; 2020-02-11), WMDE-QWERTY-Sprint-2020-01-21, WMDE-QWERTY-Sprint-2020-01-08, User-notice, Patch-For-Review, Technical-Debt, Book-Referencing, Cite, WMDE-QWERTY-Sprint-2019-12-11
Xover added a comment to T240858: Clean up implementation for "follow" cases.

@thiemowmde Theory: the initial change removed the message, which removed it from translatewiki.net. The deploy started to Group 0 on Tuesday, at which point messages were sync'ed from translatewik. The patch was reverted on Wednsday before deploy to Group 1, but still with the translatewiki sync from Tuesday. Translatewiki was updated with the restored key, but that change won't be sync'ed back until the next scheduled deploy on Tuesday next.

Feb 6 2020, 8:30 PM · WMDE-QWERTY-Sprint-2020-02-04, MW-1.35-notes (1.35.0-wmf.19; 2020-02-11), WMDE-QWERTY-Sprint-2020-01-21, WMDE-QWERTY-Sprint-2020-01-08, User-notice, Patch-For-Review, Technical-Debt, Book-Referencing, Cite, WMDE-QWERTY-Sprint-2019-12-11

Feb 5 2020

Xover added a comment to T244346: Allow Citation transclusion from a second page or series of page(s).

Hmm. So essentially list-defined references, but with the list of named references defined on a separate wikipage rather than at the end of the same wikipage?

Feb 5 2020, 2:42 PM · MediaWiki-extensions-LabeledSectionTransclusion, ProofreadPage, Wikisource, Cite
Xover updated subscribers of T240858: Clean up implementation for "follow" cases.

An attempt at some usage / requirements type notes… (and pinging @Tpt as they may wish to be aware of this task)

Feb 5 2020, 2:26 PM · WMDE-QWERTY-Sprint-2020-02-04, MW-1.35-notes (1.35.0-wmf.19; 2020-02-11), WMDE-QWERTY-Sprint-2020-01-21, WMDE-QWERTY-Sprint-2020-01-08, User-notice, Patch-For-Review, Technical-Debt, Book-Referencing, Cite, WMDE-QWERTY-Sprint-2019-12-11
Xover added a comment to T240858: Clean up implementation for "follow" cases.

I'm super confused right now.

Feb 5 2020, 8:27 AM · WMDE-QWERTY-Sprint-2020-02-04, MW-1.35-notes (1.35.0-wmf.19; 2020-02-11), WMDE-QWERTY-Sprint-2020-01-21, WMDE-QWERTY-Sprint-2020-01-08, User-notice, Patch-For-Review, Technical-Debt, Book-Referencing, Cite, WMDE-QWERTY-Sprint-2019-12-11
Xover reopened T240858: Clean up implementation for "follow" cases as "Open".

Ok, I was hoping to get clarification on actual behaviour before drawing any conclusions, but since this is scheduled to go out today in the ongoing deploy of MediaWiki 1.35/wmf.18…

Feb 5 2020, 7:46 AM · WMDE-QWERTY-Sprint-2020-02-04, MW-1.35-notes (1.35.0-wmf.19; 2020-02-11), WMDE-QWERTY-Sprint-2020-01-21, WMDE-QWERTY-Sprint-2020-01-08, User-notice, Patch-For-Review, Technical-Debt, Book-Referencing, Cite, WMDE-QWERTY-Sprint-2019-12-11

Jan 28 2020

Xover added a comment to T49544: <references/> list item must not wrap the text in <span>.

Let us please not make changes like changing <span> to <div> without thinking through the implications.

Jan 28 2020, 7:19 PM · Wikisource, Patch-For-Review, Technical-Debt, Cite
Xover added a comment to T49544: <references/> list item must not wrap the text in <span>.

I was very specifically asking for an example of bad rendering in a browser.

Jan 28 2020, 1:57 PM · Wikisource, Patch-For-Review, Technical-Debt, Cite

Jan 27 2020

Xover added a comment to T49544: <references/> list item must not wrap the text in <span>.

I feel the situation was a lot different back in 2013. It's 2020. We are not talking about XHTML any more. We use HTML 5, a "living standard". At this point, is this an academic discussion about the semantics of HTML, or does this have real-life consequences? If so, in which browsers? Is there a specific example we can look at? (Ideally with a revision ID and screenshot.)

Jan 27 2020, 7:16 PM · Wikisource, Patch-For-Review, Technical-Debt, Cite
Xover updated subscribers of T49544: <references/> list item must not wrap the text in <span>.

So... why are we not simply replacing the span with a div? We've shown several use cases where span causes problems, and I can't even think of any where div causes problems

Jan 27 2020, 12:59 PM · Wikisource, Patch-For-Review, Technical-Debt, Cite

Jan 22 2020

Xover added a comment to T215647: IA-Upload script cannot find djvm to merge files converted from JP2 back into a single DJVU..

@Tpt "No decode delegate for this image format" means the requisite image format library is not available (at runtime presuming gm is dynamically linked). First thing to check is whether the file in question is really JPEG-2000, or a mislabeled PNG/TIFF/PPM/whatever (in.ernet.dli is the Digital Library of India, and they have… uhm… original… ideas of how to encode their stuff; I often find PNG labelled as .jp2 or .jpg); and the second is to check "gm version" output for support for that file format.

Jan 22 2020, 8:02 PM · IA Upload

Jan 12 2020

Xover added a comment to T242517: Thumbnails for PDF files not found when width is not an Integer in URL link.

Looks good to me!

Jan 12 2020, 11:42 AM · MW-1.35-notes (1.35.0-wmf.15; 2020-01-14), Regression, MediaWiki-extensions-PdfHandler
Xover added a comment to T242517: Thumbnails for PDF files not found when width is not an Integer in URL link.

@Umherirrender Many thanks!

Jan 12 2020, 10:45 AM · MW-1.35-notes (1.35.0-wmf.15; 2020-01-14), Regression, MediaWiki-extensions-PdfHandler
Xover added a comment to T242517: Thumbnails for PDF files not found when width is not an Integer in URL link.

@Mpaa By my assessment it cannot have been done deliberately, as the modified code will never work in the context it is evidently being used. When combined with the misleading commit message referencing Phan, my guess is that this was an attempt to fix a warning generated by the static analyzer that just failed to spot the need for armoring there.

Jan 12 2020, 7:59 AM · MW-1.35-notes (1.35.0-wmf.15; 2020-01-14), Regression, MediaWiki-extensions-PdfHandler

Jan 11 2020

Xover added a comment to T242517: Thumbnails for PDF files not found when width is not an Integer in URL link.

See also T242422.

Jan 11 2020, 7:56 PM · MW-1.35-notes (1.35.0-wmf.15; 2020-01-14), Regression, MediaWiki-extensions-PdfHandler

Jan 10 2020

Xover added a comment to T242422: Proofreadpage attempts to use images with non-integer pixel size.

This problem coincides with deployment of MediaWiki 1.35/wmf.14 today, but I find nothing obviously connected in the changelog. A few changes mention touching calls to int(), but not in any context that would obviously be connected to this issue.

Jan 10 2020, 4:06 PM · ProofreadPage

Jan 8 2020

Xover created T242256: Request creation of ocrtoy VPS project.
Jan 8 2020, 6:20 PM · cloud-services-team (Kanban), Cloud-VPS (Project-requests)

Jan 5 2020

Xover reopened T239934: Additional Perl modules needed in default Kubernetes image as "Open".

@bd808 Adding 5 specific Perl modules and an unrelated binary (Tesseract) to the generic image isn't really a dup of a moderately large new platform architecture change.

Jan 5 2020, 8:46 PM · Toolforge (Software install/update)

Dec 21 2019

Xover added a comment to T135963: Add support for Content-Security-Policy (CSP) headers in MediaWiki.

Ideally [talking to Flickr API] would be done through the server side to preserve user privacy.

Dec 21 2019, 8:46 AM · ContentSecurityPolicy, Core Platform Team Legacy (Watching / External), TechCom-RFC (TechCom-RFC-Closed), Patch-For-Review, Epic, Security-Team

Dec 19 2019

Xover added a comment to T228594: [phetools] Wikisource OCR deletes old contents of a page, but does not generate new text..

@Koavf Which gadgets are enabled and which are on by default is up to each project.

Dec 19 2019, 6:32 PM · Upstream, Wikisource, Tools
Xover added a comment to T228594: [phetools] Wikisource OCR deletes old contents of a page, but does not generate new text..

I clearly don't know everything that's involved but there is an OCR gadget that works on en.ws, so if that functional gadget can't just replace the standard OCR button in the interface somehow, I'm at a real loss.

Dec 19 2019, 12:35 PM · Upstream, Wikisource, Tools
Xover added a comment to T228594: [phetools] Wikisource OCR deletes old contents of a page, but does not generate new text..

@Tpt First: you're awesome! :)

Dec 19 2019, 12:30 PM · Upstream, Wikisource, Tools
Xover added a comment to T228594: [phetools] Wikisource OCR deletes old contents of a page, but does not generate new text..

@Koavf It's not that simple. Hit me up on my enWS user talk page if you want the nitty gritty details. The short version is that Phe's OCR gadget (which is what this task is about, and which is what I assume you mean by the "default") is based on Tesseract, but that's not where the problem is: it's somewhere in the custom code Phe has written to provide the interface to Tesseract or its interaction with the server infrastructure on Toolforge.

Dec 19 2019, 10:02 AM · Upstream, Wikisource, Tools
Xover added a comment to T240573: Facing an issue with logging to tool account.

@Adithyak1997 Does this help at all?

Dec 19 2019, 7:12 AM · Toolforge
Xover added a comment to T228594: [phetools] Wikisource OCR deletes old contents of a page, but does not generate new text..

Is that accurate?

Dec 19 2019, 7:10 AM · Upstream, Wikisource, Tools

Dec 18 2019

Xover added a comment to T192866: Some DjVu files have too much metadata to fit in their database column.

There may or may not be a different manifestation of this problem in T240562.

Dec 18 2019, 8:35 AM · User-TheDJ, MediaWiki-File-management, Wikimedia-production-error, MediaWiki-DjVu, Multimedia, Commons
Xover added a comment to T240562: Text extraction fails on seemingly bog standard DjVu file.

It looks like this could possibly be a manifestation of T192866. In my testing, removing the text layer from a sufficient number of pages makes the problem disappear; but it does not appear removing any single (potentially problematic) page has any effect.

Dec 18 2019, 8:19 AM · MediaWiki-DjVu, Wikisource
Xover added a comment to T228594: [phetools] Wikisource OCR deletes old contents of a page, but does not generate new text..

I don't understand the distinction here.

Dec 18 2019, 6:54 AM · Upstream, Wikisource, Tools

Dec 12 2019

Xover created T240562: Text extraction fails on seemingly bog standard DjVu file.
Dec 12 2019, 11:51 AM · MediaWiki-DjVu, Wikisource
Xover added a comment to T237848: "success is not a function" JS exception on certain DjVu files.

@Tpt This is almost certainly not the same issue as T204020 (which is a dup of T219376, where some possible approaches to fix it are suggested). 20402 is basically the result of a naïve text layer extraction algorithm in MediaWiki-DjVu that fails badly when faced with unexpected data in a DjVu file, combined with the fact that the DjVuLibre tools will happily accept invalid input that it will choke on when asked to output it again. MediaWiki-DjVu can absolutely be modified such that it will fail gracefully in these cases. But, crucially, such DjVu files can be reliably identified (djvutxt --detail=page file.djvu | egrep "^failed"), and the example from this task does not exhibit that problem.

Dec 12 2019, 11:20 AM · MW-1.35-notes (1.35.0-wmf.8; 2019-11-26), MediaWiki-DjVu, ProofreadPage, Wikisource
Xover added a comment to T204020: OCR extracted from DjVu files is incorrectly assigned to pages.

This is the same issue as T219376 which contains some possible approaches to fix this.

Dec 12 2019, 11:10 AM · Wikisource, ProofreadPage, Multimedia, MediaWiki-DjVu
Xover added a comment to T237848: "success is not a function" JS exception on certain DjVu files.

It looks like the mentioned javascript error in the console is gone now (as of 1.35.0-wmf.10 today; I can't recall if I checked on wmf.8 due to the recent hiccup in the deployment calendar), but the text layer is still not loading in the example page. Absent any console messages I have no idea how to debug this further. Are there server side logs that can be checked? A test system where it can be traced? Should I open a new task for that, and if so, with what tags or projects so that it has a chance to hit the right teams' radar?

Dec 12 2019, 6:18 AM · MW-1.35-notes (1.35.0-wmf.8; 2019-11-26), MediaWiki-DjVu, ProofreadPage, Wikisource

Dec 5 2019

Xover created T239934: Additional Perl modules needed in default Kubernetes image.
Dec 5 2019, 5:09 PM · Toolforge (Software install/update)

Nov 12 2019

Xover added a comment to T237848: "success is not a function" JS exception on certain DjVu files.

@Aklapper See link in task description: https://en.wikisource.org/w/index.php?title=Page:Atalanta_-_Vol._2.djvu/18&action=edit&redlink=1

Nov 12 2019, 7:58 PM · MW-1.35-notes (1.35.0-wmf.8; 2019-11-26), MediaWiki-DjVu, ProofreadPage, Wikisource

Nov 11 2019

Xover added a comment to T230689: Preload the next page's image on proofreading view.

Incidentally, the correct place to solve this is in ProofreadPage because it has knowledge of what the next page in the sequence is. However, I suspect it would need facilities from core to do this intelligently: standard prefetching requires injecting a <link rel="prefetch" href="…" /> in the page, preferably before the browser sees it. ProofreadPage could of course "cheat" the way this gadget does (good version 1.0 / proof of concept / minimum viable product goal?), but that'd be kinda complicated, inelegant, overly specific, and prone to breaking over time.

Nov 11 2019, 10:28 AM · Patch-For-Review, ProofreadPage

Nov 10 2019

Xover created T237848: "success is not a function" JS exception on certain DjVu files.
Nov 10 2019, 10:42 AM · MW-1.35-notes (1.35.0-wmf.8; 2019-11-26), MediaWiki-DjVu, ProofreadPage, Wikisource

Nov 6 2019

Xover added a comment to T68447: Allow providing a (manual) list of titles to delete on [[Special:Nuke]].

Possibly related: T236469

Nov 6 2019, 1:30 PM · MediaWiki-extensions-Nuke
Xover updated subscribers of T68447: Allow providing a (manual) list of titles to delete on [[Special:Nuke]].

This is a common operation on the Wikisources: what on a Wikipedia would be "a page" is on Wikisource "this collection of pages in multiple namespaces". Thus having a list of pages, possibly into the thousands (one per page of a book, for example), is a very common scenario. Based on recent experience on enWS it is even more common than mass deleting all contribs from a particular user (most of our recent spammers have constrained themselves to a single page).

Nov 6 2019, 10:47 AM · MediaWiki-extensions-Nuke

Oct 25 2019

Xover added a comment to T218339: Deprecate and remove mediawiki.RegExp.

Is it expected behaviour that mw.loader.using('mediawiki.RegExp', function() {…}) will fail silently?

Oct 25 2019, 7:59 PM · Patch-For-Review, MW-1.35-notes (1.35.0-wmf.2; 2019-10-15), MW-1.35-release, MediaWiki-General, Performance-Team, Technical-Debt (Deprecation process)

Oct 23 2019

Xover added a comment to T32906: Store DjVu, PDF extracted text in a structured table instead of img_metadata.

Hmm. While DjVu and PDF (and, I think, TIFF) has explicit text layers; any kind of image can in principle contain text and could benefit from a structured way to store the OCR as actual text. We have oodles of images-of-text in JPEG, PNG, etc. formats in addition to the "book" formats (DjVu, PDF). Even book scans are not-infrequently uploaded as a couple hundred JPEGs gathered in a category (if we're lucky).

Oct 23 2019, 6:19 AM · Commons, Wikisource, Multimedia, MediaWiki-File-management

Oct 15 2019

Xover renamed T53980: Source tab not showing up in the Translation namespace from Source and page number links not showing up in the Translation namespace to Source tab not showing up in the Translation namespace.
Oct 15 2019, 7:16 PM · ProofreadPage
Xover added a comment to T53980: Source tab not showing up in the Translation namespace.

Ok, a couple of things here…

Oct 15 2019, 7:13 PM · ProofreadPage

Sep 19 2019

Xover updated subscribers of T231750: (enwikisource) Abuse filter changes request: add abusefilter actions block + autoconfirmed to see abusefilter-log-detail.

As the single community member (and admin) who expressed reservations there, I can also confirm that the discussion was a valid community consensus process; that the thread's closing was appropriate for enWS norms; that the closing comment accurately reflects the community's intent; and that this request is within the scope of that consensus. If needed we can get @Hesperian or @Mpaa (our bureaucrats) to confirm this here or on-wiki.

Sep 19 2019, 7:21 AM · AbuseFilter, User-Zoranzoki21, Wikimedia-Site-requests

Sep 17 2019

Xover added a comment to T8808: Allow import to different page name.

PS. Also: 13 years since this request was filed y'all! Probability of getting addressed tends to be inversely proportional to age of the request, so this is now the third least likely request to be addressed that I follow.

Sep 17 2019, 1:00 PM · Wikisource, MediaWiki-Export-or-Import
Xover added a comment to T8808: Allow import to different page name.

Are we looking for a fourth option of "brand new name"?

Sep 17 2019, 12:57 PM · Wikisource, MediaWiki-Export-or-Import

Sep 10 2019

Xover added a comment to T232477: Placement of pagenum span on page-spanning tables.

Hmm. Perhaps this issue could also be solved by remex being intelligent about where this particular span belongs? At least inside a <tr>, or outside a <tr> but inside a <tbody>, the correct placement of it is inside the immediately preceding <td>. If remex knows the difference between ordinary page content and the stuff inside the ProofreadPage-specified interface file it should be feasible to do this at that layer with the existing infrastructure there.

Sep 10 2019, 2:41 PM · ProofreadPage
Xover added a comment to T228594: [phetools] Wikisource OCR deletes old contents of a page, but does not generate new text..

[…] What happened or has changed that this task suddenly became "Unbreak Now!" priority, weeks after it was created?

Sep 10 2019, 2:30 PM · Upstream, Wikisource, Tools
Xover added a comment to T232477: Placement of pagenum span on page-spanning tables.

Just an idle thought…

Sep 10 2019, 2:04 PM · ProofreadPage

Aug 18 2019

Xover created T230673: Maintenance category for pages with missing index.
Aug 18 2019, 8:28 AM · ProofreadPage

Aug 13 2019

Xover created T230415: Stop ignoring paragraph and region separators in DjVu file OCR text layer.
Aug 13 2019, 1:52 PM · Wikisource, MediaWiki-DjVu

Aug 9 2019

Xover reopened T229229: Random whitespace changes and duplicate URLs as "Open".

Now it's inserting extra whitespace before the close brackets of the citation, and it's still inserting duplicate links in |url= and |pages=. See https://en.wikipedia.org/w/index.php?title=Hamlet&diff=909523776&oldid=909485888&diffmode=source

Aug 9 2019, 8:47 AM · InternetArchiveBot

Jul 29 2019

Xover created T229229: Random whitespace changes and duplicate URLs.
Jul 29 2019, 2:15 PM · InternetArchiveBot

Jul 21 2019

Xover added a comment to T228594: [phetools] Wikisource OCR deletes old contents of a page, but does not generate new text..

Hmm. I'm not sure what's going on in Ineuw's browser to cause that ve.init undefined error, but I pretty sure the general OCR gadget issue that several people on enWS have reported is related to this console message (that I'm surprised Ineuw isn't seeing, but it may be being hidden by the ve.init issue):

[Error] Error: Syntax error, unrecognized expression: An error occurred during ocr processing: /tmp/52004_20706/page_0011.tif
	error (load.php:20:880)
	select (load.php:37:233)
	find (load.php:41:184)
	init (load.php:142:753)
	jQuery (load.php:2:505)
	hocr_callback (Script Element 1:594:825)
	fire (load.php:45:980)
	fireWith (load.php:47:174)
	done (load.php:126:628)
	(anonymous function) (load.php:130)

Which is an unhandled error emitted by this line (it looks like) of phetools.

Jul 21 2019, 9:08 PM · Upstream, Wikisource, Tools

Jul 6 2019

Xover updated the task description for T219376: retrieveMetaData() in DjVuImage.php creates knock-on error when a page has invalid text layer.
Jul 6 2019, 9:53 AM · Multimedia, MediaWiki-DjVu

Jul 4 2019

Xover added a comment to T214280: Use FileImporter to import Commons-incompatible media from Commons to local wiki.

Supporting move to "All wikis in a given language" is probably a pretty tall order since this was made as a one to one tool (and how would you merge multiple divergent edit histories?). But if we could get, say, FileExporter on Commons and FileImporter on English Wikisource, it would make it a lot easier when we have to repatriate books that are about to be deleted on Commons. That should be at least within the realm of a reasonable short term goal; and with that in place it may be possible to create user scripts or other external tools that can semi-automate the "All wikis in a given language" bit.

Jul 4 2019, 1:55 PM · TCB-Team, Move-Files-To-Commons

Jun 26 2019

Xover added a comment to T226662: Database query error in en.wikisource.org Special:Preferences Gadgets on save.

I cannot reproduce this either.

Jun 26 2019, 8:51 PM · Wikimedia-production-error, MediaWiki-User-management
Xover added a comment to T114384: Standardise procedures for deprecating public-facing code.

Some thoughts from a dabbler in user scripts on WMF wikis...

Jun 26 2019, 8:14 AM · Release-Engineering-Team (Development services), Release-Engineering-Team-TODO, WMF-Product-Development-Process, MediaWiki-API, Developer-Advocacy, User-notice

Jun 14 2019

Xover updated the task description for T215558: Proofread Page extension on Wikisource is displaying wrong pages; purge on Commons file fails.
Jun 14 2019, 5:03 PM · Multimedia, MediaWiki-DjVu, Commons, ProofreadPage, Wikisource
Xover added a comment to T215558: Proofread Page extension on Wikisource is displaying wrong pages; purge on Commons file fails.

This looks to me like MediaWiki-DjVu is choking on the new file and thus never regenerating the thumbnails / page images. Not obvious that ProofreadPage is involved in this at all (except that this is where it becomes most visible). I downloaded the actual .DjVu from Commons and confirmed that the file indeed contains the fixed pages.

Jun 14 2019, 4:59 PM · Multimedia, MediaWiki-DjVu, Commons, ProofreadPage, Wikisource
Restricted Application added a project to T215558: Proofread Page extension on Wikisource is displaying wrong pages; purge on Commons file fails: Multimedia.
Jun 14 2019, 4:56 PM · Multimedia, MediaWiki-DjVu, Commons, ProofreadPage, Wikisource
Xover added a comment to T225763: The Index pages don't work on Yiddish Wikisource.

@eugrus The page numbers are generated by a community-maintained script, loaded from https://en.wikisource.org/wiki/MediaWiki:Common.js, that lives in https://en.wikisource.org/wiki/MediaWiki:PageNumbers.js. You will need various bits of supporting code from Common.js (in addition to loading the PageNumbers.js script itself) in order to get it to work.

Jun 14 2019, 4:32 PM · Wikimedia-General-or-Unknown, ProofreadPage, Wikisource

May 28 2019

Xover added a watcher for ProofreadPage: Xover.
May 28 2019, 3:59 PM

Mar 28 2019

Xover added a comment to T161456: Use Commons (individual files?) as a source for building DjVu files.

From a technical perspective, the only clear advantage to the status quo would seem to be the OCR engine (ABBYY) that IA has access to but we (currently) do not.

Mar 28 2019, 7:46 AM · Wikisource, IA Upload, Commons

Mar 27 2019

Xover updated the task description for T219376: retrieveMetaData() in DjVuImage.php creates knock-on error when a page has invalid text layer.
Mar 27 2019, 12:59 PM · Multimedia, MediaWiki-DjVu
Xover created T219376: retrieveMetaData() in DjVuImage.php creates knock-on error when a page has invalid text layer.
Mar 27 2019, 12:44 PM · Multimedia, MediaWiki-DjVu
Xover added a watcher for MediaWiki-DjVu: Xover.
Mar 27 2019, 12:14 PM

Mar 25 2019

Xover renamed T219048: Height of header and footer of ProofreadPage reduced, cannot resize text fields in browser from Height of reader and footer of ProofreadPage reduced, cannot resize text fields in browser to Height of header and footer of ProofreadPage reduced, cannot resize text fields in browser.
Mar 25 2019, 5:56 AM · ProofreadPage
Xover added a comment to T219048: Height of header and footer of ProofreadPage reduced, cannot resize text fields in browser.

All three text fields resize ok vertically here (they used to resize also horizontally, but I believe that was changed deliberately a while back). Their default size appear to be two lines.

Mar 25 2019, 5:55 AM · ProofreadPage

Jan 9 2019

Xover added a comment to T212999: Cannot edit header or footer of a WS Page ns page in Chromium based browsers.

Quick update from enWS: 1.33/wmf.12 is now live there and a quick check suggests it fixes the disappearing header and footer fields. IOW this probably confirms this was caused by T209939.

Jan 9 2019, 9:01 PM · ProofreadPage, Browser-Support-Google-Chrome
Xover added a comment to T213043: Wikisource {{Template:Rule}} is not visible in the footer.

Quick update from enWS: 1.33/wmf.12 is now live there and a quick check suggests it fixes the disappearing horizontal rule. IOW this probably confirms this was caused by T209939.

Jan 9 2019, 9:00 PM · ProofreadPage
Xover added a comment to T209939: Convert Proofpage WE layout to use display flex.

Quick update from enWS: 1.33/wmf.12 is now live there and a quick check suggests it fixes the disappearing horizontal rule and the tiny/uneditable header and footer fields. No structured testing done, but it looks very promising.

Jan 9 2019, 8:58 PM · CSS, ProofreadPage
Xover added a comment to T212999: Cannot edit header or footer of a WS Page ns page in Chromium based browsers.

Just to note for future reference, there have now been reports of this happening also in the browsers PaleMoon and WaterFox, who both seem to be Mozilla/Firefox forks, as well as Internet Explorer (unspecified version). My own tests suggest the "Horizontal layout" option has no effect either way on this (turned it off, no change), except in so far as it probably enables the "Show header and footer fields" option just above it (not sure what the default is for that). And if the header and footer fields aren't displayed at all you will of course not be able to reproduce any problems with them.

Jan 9 2019, 10:10 AM · ProofreadPage, Browser-Support-Google-Chrome
Xover added a comment to T209939: Convert Proofpage WE layout to use display flex.

@ShakespeareFan00 The deployment that (aiui) rolls back this change isn't yet live on enWS. See most recent Tech News and the thread "Issue with the FI Template display" on the Scriptorium. Based on the schedule given in Tech News, the deployment should hit enWS at some point today (or possibly tomorrow, depending on how they schedule the rollout).

Jan 9 2019, 9:57 AM · CSS, ProofreadPage

Jan 7 2019

Xover added a comment to T208901: TemplateStyles breaks a paragraph if a file is inserted inline.

@stjn I did not say that <style> outside <head> is wrong (it isn't: <style> is allowed anywhere "flow content" is allowed).

Jan 7 2019, 1:25 PM · Patch-For-Review, Core Platform Team Workboards (Done with CPT), MW-1.33-notes (1.33.0-wmf.16; 2019-02-05), Parsoid, TemplateStyles, MediaWiki-Parser
Xover added a comment to T208901: TemplateStyles breaks a paragraph if a file is inserted inline.

Hmm. This looks like a pretty naive implementation. I had expected TemplateStyles to parse out any <templatestyles> elements and inserting them in the <head> element (or through ResourceLoader or something): expanding them inline is going to create loads of problems, of which this is a perfect example.

Jan 7 2019, 11:22 AM · Patch-For-Review, Core Platform Team Workboards (Done with CPT), MW-1.33-notes (1.33.0-wmf.16; 2019-02-05), Parsoid, TemplateStyles, MediaWiki-Parser

Jan 6 2019

Xover added a comment to T212999: Cannot edit header or footer of a WS Page ns page in Chromium based browsers.

@Aklapper It seems very likely. Chromium is a fork of WebKit (the Safari engine) which exhibits the same problem (cf. the comments in the other task), and the timing (at least roughly) of this problem appearing coincides with the deployment of the changes there.

Jan 6 2019, 5:49 PM · ProofreadPage, Browser-Support-Google-Chrome
Xover added a comment to T209939: Convert Proofpage WE layout to use display flex.

@EsmeShepherd The developers are aware of the problem you are experiencing, and the plan is (aiui) to fix it (by rolling back the changes that caused it) on 7 or 8 January. At that time, or shortly after, the header and footer fields should return to the size and behaviour they had previously.

Jan 6 2019, 1:55 PM · CSS, ProofreadPage

Jan 5 2019

Xover added a comment to T209939: Convert Proofpage WE layout to use display flex.

@Tpt @TheDJ @Samwilson Looking quickly at the patch here, this is not something I imagine it's possible to do using only CSS changes. Flex box is a completely new layout model and is almost certain to require code (generated markup) changes and interact badly with other styling and scripts (including the markup produced by templates or hard coded in pages). As an example, imagine what changes would be necessary to let users switch back and forth between the two as skins. My gut feeling is that this would have to be a part of a "ProofreadPage UI 2.0" level effort in practice.

Jan 5 2019, 12:00 PM · CSS, ProofreadPage
Xover added a comment to T209939: Convert Proofpage WE layout to use display flex.

@Ankry The disappearing header and footer is more likely than not an issue only in Safari, or possibly on Retina-resolution devices (1pt = 4px, aka @2x, or higher), based on the reports I've seen (and it's probably some wonkyness related to font size: manually removing the font-size: 13px set on the text field using the web inspector makes the text field large enough to use).

Jan 5 2019, 11:42 AM · CSS, ProofreadPage

Jan 4 2019

Xover awarded T30894: Proofread Page extension needs an API module to set or change page status a Like token.
Jan 4 2019, 6:55 PM · User-DannyS712, MediaWiki-API, Wikisource, ProofreadPage
Xover added a comment to T185722: Implement a 'Page quality' log for Wikisource and wikis using Proofread Page.. .

@ShakespeareFan00: Either. Edit filters, aiui, can be managed more easily; but, based on my limited understanding, either should be able to solve this problem without actually creating an entirely new log.

Jan 4 2019, 5:45 PM · Wikisource, ProofreadPage
Xover added a comment to T120375: Adding a « save and go to next page » button.

Could not this (and would be better as) a javascript Gadget? It's just chaining together two existing operations so they can be triggered by a single button click. It would still need to be implemented, of course, but a Gadget sounds far less resource-heavy than changing the MW editing interface.

Jan 4 2019, 5:33 PM · ProofreadPage, Wikisource
Xover added a comment to T185722: Implement a 'Page quality' log for Wikisource and wikis using Proofread Page.. .

Could the log aspect perhaps be done using an edit filter? That wouldn't help retroactively (I don't think), but for all new edits they would be searchable.

Jan 4 2019, 5:29 PM · Wikisource, ProofreadPage