Page MenuHomePhabricator

Xover
User

Projects

User does not belong to any projects.

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Saturday

  • Clear sailing ahead.

User Details

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

Recent Activity

Sat, Jul 6

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

Thu, Jul 4

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.

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

Wed, Jun 26

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

I cannot reproduce this either.

Wed, Jun 26, 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...

Wed, Jun 26, 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 · Thumbor, 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 · Thumbor, 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 · Thumbor, 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 · 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

Sep 10 2018

Xover created T203962: Template transclusion count tool support for non-wikipedia wikis.
Sep 10 2018, 2:41 PM · Tools

Jun 11 2018

Xover added a comment to T196888: Comment sections are blocked by some extensions (e.g. 1Blocker).

Sigh. Yes, it was the content blocker. :facepalm: I should have double checked that first of all.

Jun 11 2018, 5:15 PM · Library-Card-Platform
Xover added a comment to T196888: Comment sections are blocked by some extensions (e.g. 1Blocker).

Observed on the last couple of release versions of Safari on macOS 10.13.4 and .5, and mobile Safari (iOS) on the last major release (11.3.1). Using the 1Blocker content blocker, but with *.wikipedia.org, *.wikimedia.org, and *.wikisource.org whitelisted (just to be sure: nothing on WMF sites should really be blocked to begin with).

Jun 11 2018, 1:41 PM · Library-Card-Platform

May 20 2018

Xover added a comment to T114450: Citoid configuration on some language wikis doesn't handle citations for book chapters correctly.

The CS1-based templates—which are actually in use across a lot of different language wikipedias—quite correctly provides distinct parameters for the title of the book and the title of a chapter within that book; much as it provides distinct parameters for an encyclopedia and a particular entry in that encyclopedia. Based on the description here, Zotero also provides distinct parameters for these, it just does so in a needlessly complicated way (changing the semantics of the title attribute based on type, when you need two "title" type fields anyway, is just asking for needless complications in implementation). Or put another way: both CS1 and Zotero appear to be capable of expressing the concepts in question here.

May 20 2018, 7:00 AM · VisualEditor, VisualEditor-MediaWiki-References, User-Ryasmeen, Community-consensus-needed, Citoid

Mar 14 2018

Xover added a comment to T188798: Change the limit of the edit summary to 500 characters on all Wikimedia wikis.

Adding a new configuration setting which is used in JS and form submit checks is more effort but that's the decent way to fix this IMO.

Mar 14 2018, 12:16 PM · MediaWiki-Comment-backend, Community-Tech, Patch-For-Review, MediaWiki-Page-editing

Mar 6 2018

Xover added a comment to T6714: Epic: Increasing the length of the edit summary.

@TBolliger That sounds like a very good first approach; but I would urge you to keep in mind the possibility, longer term, to make this configurable per project. The discussion on enwp is crystallising a lot of factors applicable to that local project, but needs will differ across projects and making it configurable will allow local consensus to determine the appropriate limit for that specific project's needs. When or whether that is implemented, just having that as part of the requirements will shape the implementation of the short term solution: for example in terms of truncate/disclose functionality for revision history views to deal with revisions imported from a project with larger local limits.

Mar 6 2018, 7:05 AM · MediaWiki-Comment-backend, Patch-For-Review, Contributors-Team, Epic, TCB-Team, German-Community-Wishlist, Tracking-Neverending

Mar 3 2018

Xover added a comment to T6714: Epic: Increasing the length of the edit summary.

It would not be a great idea to vary per project. At a minimum, wikis would then interfere with each other when some revision is exported and imported to another wiki with lower limit.

Mar 3 2018, 12:23 PM · MediaWiki-Comment-backend, Patch-For-Review, Contributors-Team, Epic, TCB-Team, German-Community-Wishlist, Tracking-Neverending
Xover added a comment to T6714: Epic: Increasing the length of the edit summary.

As I read various stuff related to this, including @brion's / Community Tech's RFC page, it seems the underlying database and backend change to 1000 bytes has happened previously, and that the March event was actually just removing a user interface level limitation to the status quo length (250 bytes or whatever it was). If that is so, then there is existing front end code to limit what editors are allowed to input in this field that can be deployed with a limit in line with community wishes regardless of what the backend technically allows. And in front end code it should be much easier to make this limit based on characters and not bytes, to ease the burden on the non-Latin communities.

Mar 3 2018, 10:40 AM · MediaWiki-Comment-backend, Patch-For-Review, Contributors-Team, Epic, TCB-Team, German-Community-Wishlist, Tracking-Neverending

Mar 1 2018

Xover added a comment to T101075: Do not save unused (or deliberately removed) suggested parameters when inserting or editing transclusions.

I think the approach suggested by @Krinkle above may be overkill.

Mar 1 2018, 8:24 PM · VisualEditor-MediaWiki-Templates, VisualEditor
Xover added a comment to T153431: Decide on editor requirements for creating a Library Bundle.

As for recent activity, that's a valid concern, but we're aiming for the requirements to be checked at the point of access, such that if you're away for a month and make 10 edits the first day you're back, you'd get access again straight away, not the following month. Does that sound more reasonable?

Mar 1 2018, 8:07 PM · Library-Card-Platform-Proxy
Xover added a comment to T153431: Decide on editor requirements for creating a Library Bundle.

Hmm. I can easily be away from the project for a month from time to time. It'd be kinda annoying to be cut off from access to partner sources when I got back. Or picture the scenario where I edit every other month: I'm away for a month, get cut off, am back to editing for a month without access, and then get access for the next month when I'm not editing.

Mar 1 2018, 7:44 PM · Library-Card-Platform-Proxy

Feb 27 2018

Xover added a comment to T188330: VisualEditor should not insert empty parameters from the TemplateData dialog.

Note that there are nuances to this. For instance, when editing an existing citation using VE, any existing (in wikimarkup) empty parameters that are present should not be removed. There may be other such gotchas that I'm not thinking of right now. Perhaps the most surgical (least risk) approach would be to "remove" (not insert) empty parameters if and only if they were added to the editing interface by VE due to being "suggested" in the TemplateData.

Feb 27 2018, 6:00 PM · TemplateData, VisualEditor

Feb 20 2018

Xover added a comment to T187048: IABot erroneously reports zero links in article.
  1. Edits are now made by the user running the tool and not IABot, and users are responsible for any edits they make regardless of whether they were manual or automated.
  2. Wikipedia doesn't mandate a single reference style, so short citations with full references in a separate section are by definition equally a part of the concept "references" as full references inside <ref> tags.
Feb 20 2018, 6:08 PM · InternetArchiveBot
Xover added a comment to T187048: IABot erroneously reports zero links in article.

@Cyberpower678
Is that (must be inside <ref> tags) a requirement? Is it documented? It seems really non-intuitive that URLs inside the various cite templates (all the CS1/CS2 templates take a |url= parameter) are not checked. That would make IABot non-functional for any article that uses short citations. And what about plain extlinks?

Feb 20 2018, 9:53 AM · InternetArchiveBot

Feb 12 2018

Xover created T187111: Live status of URLs on paywalled sites can't be changed to dead.
Feb 12 2018, 7:26 PM · InternetArchiveBot (v2.0)
Xover created T187048: IABot erroneously reports zero links in article.
Feb 12 2018, 11:01 AM · InternetArchiveBot

Feb 8 2018

Xover added a comment to T183087: Misleading doc for mw.hook('wikipage.content').

Removing " or #wikiPreview (live preview root) " in the documentation would solve this right?

Feb 8 2018, 5:45 AM · Documentation, JavaScript

Dec 17 2017

Xover added a comment to T183087: Misleading doc for mw.hook('wikipage.content').

Well, the code I looked at would be…

Dec 17 2017, 4:32 PM · Documentation, JavaScript
Xover created T183087: Misleading doc for mw.hook('wikipage.content').
Dec 17 2017, 11:34 AM · Documentation, JavaScript

May 20 2017

Xover added a comment to T163098: Fix the Watchlist visual layout.

Ok, getting sufficiently annoyed with the status quo, and inspired by the Wikisource gadget, I hacked up a user script for enwiki to illustrate the point.

May 20 2017, 8:25 AM · MediaWiki-Interface

May 14 2017

Xover updated subscribers of T164300: OAuth related signup issue preventing login.

Note that this is likely to affect every single account registered before SUL (so 2007/2008), and those that have stuck around the projects for 10+ years may be "high value targets" for TWL (I'm guessing; I may be wrong). It is also likely to affect every tool that needs the age of the account, and not just the Library Card Platform (to wit: it hit the IABot Management Interface, cf. my comment above; and the "Popups" gadget on enwiki exhibits similar symptoms).

May 14 2017, 6:49 PM · Library-Card-Platform

May 10 2017

Xover added a comment to T164300: OAuth related signup issue preventing login.

One possible cause for this, cf. T164974, is that the user account is old and has no registration date. Might be worth checking as trigger anyway.

May 10 2017, 8:10 PM · Library-Card-Platform

Apr 18 2017

Xover added a comment to T163098: Fix the Watchlist visual layout.

Don't discount what's possible due to politics - the politics across the projects vary considerably, and Wikisource actually has this already: https://en.wikisource.org/wiki/Wikisource:Scriptorium/Archives/2015-07#New_Gadget. That may be a gadget, but there's definitely demand for this being properly implemented in the skins themselves.

Apr 18 2017, 7:08 PM · MediaWiki-Interface
Xover added a comment to T163098: Fix the Watchlist visual layout.
  • View/edit/etc would likely make more sense as tabs (cactions menu). CentralNotice is an another example of a special page with extra tabs on, so there is precedent, and this would be a use that would be very clear to users.
Apr 18 2017, 7:02 PM · MediaWiki-Interface

Apr 17 2017

Xover renamed T163098: Fix the Watchlist visual layout from Feature request: fix the Watchlist to Fix the Watchlist visual layout.
Apr 17 2017, 6:23 AM · MediaWiki-Interface
Xover created T163098: Fix the Watchlist visual layout.
Apr 17 2017, 6:20 AM · MediaWiki-Interface