User Details
- User Since
- Jun 5 2015, 5:03 AM (443 w, 4 d)
- Availability
- Available
- IRC Nick
- samwilson
- LDAP User
- Samwilson
- MediaWiki User
- Samwilson [ Global Accounts ]
Today
The core patch above is ready for review. I'll fix up the Vector-2022 icon display separately (so after reviewing the above, please put this back to in-development).
Yesterday
All done now I think.
- Improve CI config to make the epubcheck version number a variable: https://github.com/wikimedia/ws-export/pull/465 (merged)
- Also now bump to 5.1: https://github.com/wikimedia/ws-export/pull/485 (ready for review)
- The last part of this I think is to add some random book checks to CI: https://github.com/wikimedia/ws-export/pull/484 (ready for review)
This might be a duplicate of T337649.
I'm getting this error today with e.g. this file.
This is fixed now, with the above patch merged.
Don't hesitate to report any other issues (or new ideas for improvements).
Sat, Dec 2
I've had a go at this as well: https://github.com/wikimedia/ws-export/pull/479
Fri, Dec 1
Maybe someone at Wikimedia OCR project can tell us how they manage to get the full resolution image from every page
SVG Translate works by uploading a new version of an existing file. If someone doesn't have rights to do that then the tool can't work. Users who don't have the autopatrol right are blocked from doing this, because in many cases (other than translating SVGs!) it's not a desirable thing to do.
All sorted now?
Oh. Umm. Well, this is embarrassing! :-) I put them backwards.
Thank you for raising this!
The abusefilter-warning-file-overwriting message explains this more:
Thu, Nov 30
A patch to add a workaround for this: https://github.com/wikimedia/wikimedia-ocr/pull/120
I think this task is actually the same issue as T296912: WikisourceOCR: Google OCR is not working.
PR for re-sending the full image data: https://github.com/wikimedia/wikimedia-ocr/pull/120
Those italic characters are mathematical symbols and shouldn't be used for normal text. (For example, 𝘕 is "Mathematical Sans-Serif Italic Capital N".)
This could perhaps be handled similarly to the situation of restoring a page when there's been a subsequent revision. In both cases (when we're on an old revision, and the stored data is based on a newer revision; or we're on the latest revision, but the stored data is based on an older revision) we could let the user know.
Yeah, we should probably make the tool fail more gracefully in this situation! Sorry for the failure.
I think all of this is already possible with $wgRestrictDisplayTitle (which is in core).
Wed, Nov 29
WikimediaOCR is in the Wikisource extension, which doesn't seem to already have a tracking task.
https://www.mediawiki.org/wiki/Template:Js_doclink creates links of the above format, so it'd be good to have those working again (although I'm sure that template will be updated with the new URL structure once the new docs are all sorted out).
I'm not sure I understand the request here. Are you talking about the <head> element? It sounds like you want to add more formatting to the <title> element.
Tue, Nov 28
I agree with @MusikAnimal I think, now I've used it for a few weeks. Edit Recovery should take precedence, as long as it's easy to discard the recovery data.
I'm trying to replicate this but can't yet. Do you think it's related to T351821: Edit Recovery interaction with browser data recovery? It sounds like it's not seeing any difference between the 'original' data and what's now stored, probably because it's got the wrong idea of what 'original' is.
Thanks. Tooltip added to the patch.
Good point, thanks.
I think it's just that the item has 1637 pages, and it can't handle it. Does the PDF at IA suffice, or do you specifically want a DjVu?
Mon, Nov 27
T329975 would not help if the user isn't actively editing
Great, sounds good!
Fri, Nov 24
Yeah it's only the cross-loading from wikisource.org that's the concern, the others (Commons etc.) should be fine.
I'm only seeing this happen when I'm loading resources from wikisource.org on en.wikisource.org. In my case that was only the InterWikiTransclusion gadget, and with that turned off I'm no longer getting logged out on enwikisource.
Thanks @JSengupta-WMF, I've added that icon. I've started work on hiding the link when it's not needed, but have a couple of questions:
Wed, Nov 22
@JSengupta-WMF this is just a stub, I'm sure there is more to figure out, please edit as you see fit.
Done.
This was done a while ago, but I forgot to close this task.
Tue, Nov 21
This could just be as designed but on the Timeless skin, it shows Special Page twice.
I've been thinking about this for a bit, and am I right in thinking that it's the same situation when the user didn't close the first edit window at all? i.e.:
Sun, Nov 19
After discussion at WikiCon 2023 Brisbane today, it's been decide to archive the databases and files of these two wikis (np and nys), and to not try to get them functioning again at this late stage.
Sat, Nov 18
Fri, Nov 17
I've set the logo and favicon to the one at https://stardit.wikimedia.org.au/logo.png but we'll want to optimize the files used for each of those. It'll do for now I think, because there's also the matter of what skin should be used, and that'll change the logo requirements.
Wed, Nov 15
Thanks @GMikesell-WMF that's very interesting: so just to clarify, am I understanding the flow correctly:
An idea that CommTech talked about in a meeting recently was to make it possible to add something like mw.EditRecovery.enabled = false; to one's global.js or common.js so that advanced users would have a way to turn it off without adding to the UI for everyone else (there's a concern about having too many preferences already). There's also now Special:EditRecovery, which could be a good place to house a preference toggle, if we did want it to be a general thing but still keep it out of Special:Preferences (although that'd make it harder to handle GlobalPreferences, I think, and perhaps there's a use case for wanting Edit Recovery on only some wikis).
Tue, Nov 14
The new Edit Recovery feature should be an improvement in this situation: the edited wikitext is saved in the browser, and after the user logs in again and returns to editing that page (even if they've closed the browser in the meantime) they'll get their edit back.
This is an old issue, and I think the basic issue has been resolved long ago. There is also the recent addition of the Edit Recovery system which should ensure that even if someone doesn't read the warning ("You can view and copy the source of your edits to this page.") and navigates away from that page they'll still be able to recover their edit. So I think this task can be closed as resolved.
Mon, Nov 13
The first part of this is ready for review. It's a very basic list of pages, but mainly is about setting up the structure and getting ready for when the design's ready.
Sun, Nov 12
This seems to be related to accessing a member of a bound object, e.g. removing page.url from the following fixes the error:
The RedirectManager extension might be a solution to this. It provides a way to list all existing redirects, and add new ones, while editing a page.
Sat, Nov 11
Fri, Nov 10
Thanks @GMikesell-WMF sounds good.
Wed, Nov 8
Tue, Nov 7
@GMikesell-WMF I'm not able to replicate the bottom-scrolling bug. I'm editing the Dingo article as you mention, but when I discard the changes it correctly scrolls to the top (which is what this line of code is meant to be doing). Can you help me narrow this down (browser, page size, other gadgets etc.)?
I think this task is all done, and all missing parts are now tracked in other tasks.
Yeah that makes sense. I guess hyphenation is really more a prose feature than something we'd normally want in a button. Shall remove that CSS.
Possible issue: If you click on "Discard Changes" from the Changes Recovered pop-up, it goes to the end of the article. Shouldn't it start at the beginning?