User Details
- User Since
- Apr 16 2017, 6:32 PM (117 w, 3 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Xover [ Global Accounts ]
Sat, Jul 6
Thu, Jul 4
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.
Wed, Jun 26
I cannot reproduce this either.
Some thoughts from a dabbler in user scripts on WMF wikis...
Jun 14 2019
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.
@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.
May 28 2019
Mar 28 2019
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 27 2019
Mar 25 2019
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.
Jan 9 2019
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.
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.
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.
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.
@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 7 2019
@stjn I did not say that <style> outside <head> is wrong (it isn't: <style> is allowed anywhere "flow content" is allowed).
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 6 2019
@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.
@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 5 2019
@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.
@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 4 2019
@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.
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.
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.
Sep 10 2018
Jun 11 2018
Sigh. Yes, it was the content blocker. :facepalm: I should have double checked that first of all.
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).
May 20 2018
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.
Mar 14 2018
Mar 6 2018
@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 3 2018
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 1 2018
I think the approach suggested by @Krinkle above may be overkill.
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.
Feb 27 2018
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 20 2018
- 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.
- 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.
@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 12 2018
Feb 8 2018
Dec 17 2017
Well, the code I looked at would be…
May 20 2017
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 14 2017
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 10 2017
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.