User Details
- User Since
- Apr 16 2017, 6:32 PM (309 w, 1 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Xover [ Global Accounts ]
Wed, Mar 15
Wed, Feb 22
Could we add to the checks for this epic:
Feb 16 2023
At least one of these $parser->addTrackingCategory("lst-invalid-section-category"); calls is bogus. s:Category:Pages transcluding nonexistent sections is filling up with entries for pages that are quite correctly transcluding a named section. My guess is the last one, but I haven't traced it.
Jan 28 2023
So... still no news?
Jan 14 2023
Jan 2 2023
Dec 8 2022
Checked on the web interface (ocr.wmclod) by manually adding "https:" to the URL and it worked fine, so it does indeed seem to be just a dumb regex match problem. Easy bugs are the bestest bugs! :-)
@Soda I think you're touching code related to this for other reasons, so you may want to be aware of this task. In addition to $prpImage being undefined, pages such as this also trigger an error notification from OSD that there's no image.
Dec 1 2022
This is really annoying for the Wikisourcen since their formatting needs follow whatever the text they are reproducing used, rather than a project-specific manual of style. It is very common to have typical linkable phrases (names of authors, say) formatted with multiple styles (i.e. multiple formatting templates) such that the template(s) cannot be moved outside the link.
Nov 10 2022
Transclusion with PRP does not show the page image, but rather the wikitext of the associated Page:-namespace page. Does this wikipage have any contents? And if so, what is it? If you check the mainspace page in your web browser’s Web Inspector, do you find a node with #prp-pages-output?
Ok, I can confirm that all the pages in the query results above are "naked" pages (not connected to a scan).
For sanity-checking you can use Phe-tools' statistics, where the "w/o scans" column for a given language Wikisource should show a number roughly the same as the (COUNT) number of results of your query. I can also probably dig up the exact query Phe's tool is using if interesting, but it'll be several years since it was tweaked (I think Phe went inactive around 2015/2016 or so).
Nov 5 2022
Nov 2 2022
Oh, indeed. Normal TableStyles are scoped to .mw-parser-output, but Index:-styles are scoped additionally to .prp-pages-output in mainspace and .pagetext in the Page: namespace. In Page: namespace the whole content (including header/footer) is contained within .pagetext and so it works fine. But in mainspace the rendered references are not mediated through Proofread Page (it uses Cite directly) and so are not contained within .prp-pages-output and the selectors cannot match.
Oct 29 2022
@Umherirrender: Thank you! Will this default to the main slot like other API calls, or will the slot need to always be specified explicitly?
@Candalua Do you have a page exhibiting this problem? And do you mean .prp-pages-output or .mw-parser-output (to which TemplateStyles are normally scoped)?
Oct 28 2022
Oct 26 2022
Sep 6 2022
Gah. I'm religiously in favour of trimming away unneeded stuff in the UI (cf. T163098), but as I read the above comments I realise I rely on that behaviour too: for lots of pages I use the tab to get a "clean" (or just specific or predictable) version of the page, or a related page (i.e. talk vs. main vs. history etc.). And perhaps key here, not just on special pages. That is, if just special pages change (no tab but grow a reset button in the page-specific UI) I can't just retrain muscle memory, it'll end up being a constant impedance.
Note that only the following are documented targets of mw.util.addPortletLink():
Aug 25 2022
The "Source" tab is a proper peer to "Page" and "Discussion" on Proofread page-based wikis (like the Wikisourcen), so mw.util.addPortletLink() is not an appropriate fix for this problem.
Aug 13 2022
@He7d3r Is this task still relevant? It seems to refer to a specific bug in a specific on-wiki/community maintained script on mulWS (possibly cross-loaded on ptWS, but not on e.g. enWS where Easy LST is a local Gadget),and one that has either been fixed or mooted by subsequent changes. Perhaps this task can be closed as (now) Invalid?
@Nemo_bis @Samwilson @8ohit.dua If BUB is dead can't this task be closed as Invalid? Or did it get resurrected somewhere and where this task is still relevant?
Jul 27 2022
Ok, since the Vue.js decision announcement I've been looking for some kind of status or guidance or roadmap for client-side UI for Gadget and User script developers. That used to be jQuery UI, but upstream put that in maintenance-only mode in 2018 and it was deprecated in MW 1.29. The new hotness was OOUI, but it was never very suitable for this use case and realistically now will never be. Where the puck is going is, from all appearances, Codex; but try as I might I can't find more than incidental mentions of User scripts and Gadgets as a use case (and mostly in the "select a framework" Phab task). There's all of one open task on the Codex workboard (T311099) related to this, and that's just the icons.
@egardner wrote:
- Archive, delete, or prune old Vue Migration Team pages as necessary (may need help from someone with admin privileges to delete pages).
Jul 13 2022
Absent further comments let me be a bit more direct: looking at T304303 I see no upside that to me justifies breaking this long-standing and core end-user-visible functionality. Page-spanning constructs (e.g. tables, like the tables of contents in just about every book) are now literally impossible to work with when live previews are on, and it is in practice impossible for a user (even experienced users) to tell what's going on or how to work around it. IMO, if this cannot be fixed some other way relatively soon the triggering change will have to be rolled back.
Jul 7 2022
Jul 6 2022
Jul 5 2022
This bug affects not just the proofread status, which is more cosmetic than anything, but also all other uses of the header and footer, which is a lot more troublesome. Most obviously it means you can't preview any changes to the content in the header/footer (a running header, for example); but it also breaks the use of any page-spanning templates. For example, on enWS Template:TOCstyle generates a table and relies on having {{TOCstyle|header=yes}} in the header so that when invoked in the body with {{TOCstyle|continues=yes}} it can output only a markup fragment. Since the preview doesn't have the header the body ends up being parsed as generic unordered list markup. enWS has a number of templates that operate on this model. And without testing I imagine it also will affect any other page-spanning constructs such as basic table wikimarkup (multipage tables are common in all sorts of works).
Ok, I've checked all usages on enWS (and noWS, incidentally) and apart from user scripts for inactive users, there is only one remaining instance. I've notified the user, but I suspect the script isn't actually in use currently (it hasn't been modified since 2011). In other words, enWS should be fine when the train rolls around tomorrow. But I'm still a little worried about the other projects.
Incidentally, this change seems to have some sort of bearing on T53980 (from 2013!), though I'm not sure of in what way yet (makes it easier? harder? fixes it as an incidental effect? makes on-wiki workarounds easier?).
Jun 5 2022
@BBlack The last status update on this bug was ~18 months ago, and indicated the issue was an upstream bug and you were following up there, with a fallback to a WMF-specific patch if upstream got stuck. I see no indication there is any question this behaviour is a bug (cf. eg. Krinkle's comment above). It's also a problem that makes certain pages inaccessible on all projects, breaks contribution histories and other core features for certain users, and necessitates manually prohibiting a character in page and user names that is intended to be permitted.
Mar 6 2022
Hmm. Then I think the problem statement is a little bit the wrong way around: it reads as if the aim is to lock down a currently reigning "Wild West" state of affairs, but in light of your clarification it sounds like the focus is more to enable a use of third-party resources that are difficult or impossible to (legally) do today but which would be of benefit to the Movement. And, obviously, when enabling such use it is desirable to do so in a controlled way that prioritises privacy, is sustainable, does not negatively impact performance, and so forth; but this then is not the focus so much as the consequence.
Mar 2 2022
I'm confused by this problem statement. The Privacy Policy already forbids anything on Wikimedia projects that causes the UA to contact any third-party website, including Toolforge and WMCS, for any purpose (any HTTP header and the client IP are covered by the definition of "Personal information"). So regardless of whether it's executable code, an image, a webfont, JSON/JSONP data, etc. it is currently bright-line forbidden. What, then, would this "clear Wikimedia policy on the use of third-party resources" cover?
Feb 25 2022
Feb 24 2022
The layout changes for the pagelist in this task are kinda suboptimal. There seems to be significantly increased margins around each page label, and in addition each label is now inline rather than block so the containers (on which the background is applied) collapse down to essentially just the character boxes. See the before—after screenshots below:
Feb 13 2022
Feb 12 2022
Jan 31 2022
Jan 30 2022
Jan 24 2022
Dollars to dimes they're just scraping works for some ebook site based on the OPML.
Jan 17 2022
Jan 13 2022
It is probably worth revisiting, yes, but note that interactive performance here depends on dynamically generated "thumbnail" images, where the generation involves shelling out to ghostscript (for PDFs) and ddjvu (for DjVu) to extract a given page from a possibly ~1GB multi-page document and rendering it to a JPEG. Ghostscript, in particular, can (anecdotally) take ~20 seconds to do this.
Jan 12 2022
Last I heard (I could be wrong), MediaWiki-extensions-PdfHandler (ping @Tgr) uses Ghostscript to render PDFs to JPEG thumbnails, meaning this is most likely an upstream bug affecting certain born-digital PDFs. Best case for fixing it is probably using a newer version of ghostscript, which I'm guessing would be blocked on T289228. If it can be reproduced in base latest-version ghostscript it should probably reported upstream, and a fix here would then also depend on when upstream makes a release with a fix. Alternately, there is T38594; but I suspect it'd be fairly resource-intensive on the MediaWiki side, and I have no idea what the relative merits of Ghostscript and MuPDF are. A switch might conceivably have a positive effect on the problem described in T242169 (or it might not; or it might make it worse).
Jan 7 2022
The user that first reported this issue on enWS has tested and confirmed that it is now fixed for them. And my own testing concurs.
Crap, I notice we don't have any regular backport windows until Monday. While this wasn't train-blocking/rollback when noticed, it's probably UBL-y enough that it needs to go out as an emergency backport. It doesn't break the primary workflow in that the Wikisourcen can still edit pages, it does break the zoom/pan for the reference page image (which is highly-used functionality) and partially breaks (blocks) the UI for setting page status (particularly for people with page zoom on in the browser, which is a major accessibility issue and primary workflow).
Jan 6 2022
Updated patch looks good to me, but I'm not sufficiently familiar with the context there for that to mean much.
Patchdemo looks good to me: no console errors, all the OSD stuff (zoom, rotate, etc.) looks like it works, and it even seems to fix the unresponsive radio buttons that were reported on-wiki.
Ah, oh, yes, I see. When we start, $imgContHorizontal is initialized to null (what's the point of that long chain of vars getting set to null at the top? They should either be set to something useful or their initialization might as well be deferred until first used.). It doesn't actually get assigned any value until toggleLayout() is called, and there it's wrapped inside a conditional such that it is only initialized if the layout is already horizontal (if (!isLayoutHorizontal)). When we start in vertical mode the var is never initialized, until something actually triggers toggleLayout(); but then a few lines later $imgContHorizontal.add() is called regardless of which branch was picked in the preceding conditional.
But why is $imgContHorizontal undefined here?
Jan 5 2022
@santhosh You're listed as the maintainer for jQuery.WebFonts so I tagged you on this. If this isn't your bailiwick I'd appreciate a pointer in the right direction.
Jan 3 2022
Dec 29 2021
@Agabi10 Did you give up on this patch? It looks really useful to me, and from the review comments it didn't look like there were any insurmountable problems (just maybe some documentable limitations due to the architecture context).
There's no obvious reason Scribunto should unconditionally enforce this when Lua as such doesn't, but that's an issue of defaults and somewhat orthogonal, IMO.
This sounds really cool, but I am having trouble seeing what the use case for it is. What kind of data would one put in a "derived slot"? And since it is programatically generated, why not handle it in the parser and its cache?
Dec 22 2021
Dec 16 2021
Based on that error message it smells like a namespace collision. deWS has a lot of site-local JS that uses (and defines) a "SetCookie" function. That's a pretty generic name for such a function, so it may well be clashing with a name from elsewhere (e.g. the recent OSD stuff).
@Satirdan_kahraman The cover image (page 1) just needed a null edit, so there was apparently some kind of caching issue. I checked a few of the pages that have not yet been proofread and they appeared to load correctly.
Dec 2 2021
@bd808 I still can't find any mention of Toolforge on mw:GitLab or its subpages, so do we need a separate task to set policy for access/groups/directory layout in GitLab? What's currently documented only deals with WMF and WMDE components, and I am not immediately convinced that the assumptions for those hold in the context of Toolforge.
Dec 1 2021
@Tpt As best I can tell, the automatic next link on the main page was the existing behaviour. When the work's title was in $indexLinks[0], the if test inside the for loop would get a hit and set $current. The prev link test then explicitly excluded it by skipping index 0, but the next test just checked that it wasn't the last entry in the array ($i + 1 < $indexLinksCount) and so would add a next link on the page corresponding to the work's title.
Nov 30 2021
Hmm. I may be insufficiently caffeinated just now, but…
Nov 24 2021
@Alex_brollo I don't think reversing a change that brings big improvements is the way to go (and this cannot function as a gadget), but your use case is interesting. Instead of trying to manually undo the changes I would suggest you try to find ways to use the new facilities to do what you're after. A lot of it I would expect to already be possible (OSD has an API exposed that can be used), and what's missing are probably good candidates for adding. If you explain your needs it might be possible to suggest alternate approaches for them.
Nov 20 2021
Hmm. No smoking gun there that I can find.
Nov 18 2021
Dollars to dimes it's choking on c:File:Cyclopaedia of English Literature 1844 Volume 1 page 548.djvu which is in that category and is currently showing up with 0x0 dimensions and 0 pages. The djvudump structure for this files is:
Possibly triggered by the changes from T275268. Ping @Ladsgroup.