If you want to know, ask.
Sep 15 2020
Sep 5 2020
Aug 5 2020
What third-party website? Can MediaWiki servers not locally host fonts?
Let me add to the chorus here: the default on many systems is Comic Sans which is far from ideal. Is this more difficult than simply editing the local MediaWiki.css?
Jul 22 2020
Wow, I didn't realize that this has been sitting around for 6.5 years but it hasn't been deployed to any WMF wiki yet... Hm.
Jul 21 2020
<del>"Import from Incubator" is checked but there are many files that are not ported over from mul.ws and that will fundamentally break the scans. (That's in addition to user pages, templates, modules, etc.)</del>
Jul 11 2020
Jul 10 2020
Generating thumbnails and serving up content in MediaWiki as AVIF images. My goal is to be able to use AVIF images in the exact same way as JPEG and PNG.
Jun 29 2020
I did read it. My point is that I only read it *after* someone pointed out its scope. The vague title does not make it clear what the bug is actually *about* which I would think on first blush was a totally different issue related to the rebranding controversy. Hence, I am asking if someone can make a more descriptive title that actually gives a hint as to what the content is of this bug in particular.
Jun 28 2020
I made a duplicate of this task because I searched for titles about "blacklist" or race and didn't find this. Can we get a more descriptive name for this bug? On first glance, I would think this was about the 2030 rebranding if anything.
Jun 22 2020
Agreed: minus should be used, not hyphen-minus. I was just clarifying for others who can't obviously tell which figure is in the infobox.
To be clear, the infobox Doc just mentioned uses < - >, which is the hyphen-minus character: https://en.wikipedia.org/wiki/Hyphen-minus rather than < − >, the minus sign: https://en.wikipedia.org/wiki/Plus_and_minus_signs#Minus_sign
May 24 2020
May 23 2020
Apr 12 2020
Appears resolved. Can others help document at https://wikitech.wikimedia.org/wiki/Incident_documentation/20200412-eqiad_down
Apr 7 2020
Is this why Wikidata-related modules and links in the toolbox are not working at en.wp?
Apr 6 2020
Mar 8 2020
Mar 3 2020
To be clear, this request would allow us to still have standard running text MediaWiki pages on Wikispore and not convert it into a Wikidata-style database, correct?
Additional functionality that is related: confirming email does not work (the site claims that it sends a confirmation but it doesn't) and consequently getting email updates from one's watchlist.
Mar 2 2020
This is not urgent/break now but it's pretty important for maintenance on several wikis and has evidently been broken for four or five months.
Feb 13 2020
I can confirm that this is impacting many projects. E.g. https://en.wikipedia.org/wiki/Special:WantedPages and https://www.wikidata.org/wiki/Special:WantedPages and https://species.wikimedia.org/wiki/Special:WantedPages haven't been updated since 2019-11-25 and the latter two claim that they will be updated every two weeks or so (en.wp has a huge warning that it's rarely updated).
Feb 7 2020
I don't want the error.
Feb 6 2020
Jan 25 2020
I have an account to rename there as well. I hope that SUL can resolve this.
Dec 21 2019
Why is something that is so straightforward and so critical take so long?
Dec 19 2019
I do use it but by having be an opt-in gadget rather than the standard, we run the risk of losing editors, as mentioned above.
Fixing problems like this and maintaining tools is difficult. In this particular case, there is a very straightforward quick fix, which is to use Tesseract's OCR tool and replace the default one. It works very well and is not broken. I'm not sure if the developers are busy or are trying to make the perfect the enemy of the good or what but a really easy way to resolve this in (what I assume as someone who is not a Wikimedia developer) five minutes is to drag and drop Tesseract's tool into some folder on some server and overwrite the standard OCR that no longer works. Long-term solutions are good, the development team's time and expertise are precious, and protracted bugs that just end up with a lot of talking about talking don't help anyone, so this seems like the best solution but I'm willing to admit my own ignorance if someone can come up with a better solution.
Dec 18 2019
Dec 17 2019
At the risk of sounding condescending, this *is* fundamental to Wikisource. While some sources are digital-native, the majority of what Wikisource is is transcription of print sources and that is impossible without the ProofreadPage which relies on an OCR scan to reduce easily between 30 and 90% of the workload, depending on the source. Again, if what you need is a quick fix to descalate this, just make the Tesseract OCR scan the actual tool in Wikisource and we can sort out the details of a best practice later. This needs to be fixed ASAP.
Nov 24 2019
Correct: we need both standard modules and templates included without having to remake them or import every revision over and over again, plus we want to include some content in form of actual pages from other wikis like Meta.
Yes, I meant outreach.wikimedia.org.
Nov 20 2019
I object to deletion: as long as we still own the domain names (that is, "we" being the WMF, not us personally), URIs should stay active and point to something meaningful. The only thing we ever should have outright deleted was the Siberian Wikipedia.
Oct 14 2019
Oct 8 2019
I escalated the priority: this is fundamental to how Wikisource operates. If we want to replace this with Tesseract as a solution, that's fine--just do so for all users.
Oct 7 2019
Agreed. Not sure whom I can personally thank for this after waiting so long for (e.g.) nap.ws but thanks to whomever it is that is doing all this valuable work.
Oct 6 2019
I escalated the status--this is pretty vital to how ru.wn functions.
Sep 19 2019
Sep 7 2019
I changed the status: this is a critical part of en.ws.
Aug 25 2019
Is it any trickier than it was five years ago? It seems like making new wikis is a lot harder than it was. Is there some kind of structural problem here? We've had some non-standard names to be changed (like roa-rup.wp or zh* Wikipedias at T10217) for years and years.
Aug 15 2019
nap.ws is being imported as I post this.
Aug 2 2019
Aug 1 2019
Thanks. Not sure how you don't see a Facebook button on that blog post but it's there.
I have a dozen or so blocking extensions and Facebook Container blocks it.
Jul 21 2019
Jul 2 2019
Sounds like a bug.
Jul 1 2019
Re: Wikitravel: Don't compare their custom HTML homepage in English. Compare (e.g.) https://wikitravel.org/wiki/en/index.php?title=Western_Sahara and https://wikitravel.org/wiki/en/index.php?title=Western_Sahara&mobileaction=toggle_view_mobile, which does work.
May 13 2019
I'm still not clear on why *deletion* is necessary. Just leave the domain and unlock if we want more tests later. Unlocking a wiki is easier than setting up a new domain.
Mar 3 2019
Sorry. It looks like it has been done, actually--I forgot. This is all over with and fixed. Thank you, Reedy.
Maybe this will help you? https://commons.wikimedia.org/wiki/Commons_talk:Video2commons#Uploading_errors--I_need_help
I don't understand what you're asking.
It was uploaded as File:116th_United_States_Congress_House_Floor_-_2019-01-16.webm
Baller. Thanks a lot. Can you also upload 2019-10-16.webm?
Mar 2 2019
What? Can you reword that?
Feb 8 2019
This is enabled on testwikidata (and also allows for testwikipedia, test2wikipedia, and testwikidata itself). Is there any idea when it will be enabled in Wikidata?
Feb 6 2019
Jan 31 2019
Escalated to unbreak now to bring attention to the vandal: https://phabricator.wikimedia.org/p/Funnyjokes2019/
Alternate proposal: create
- [langcode].tv .[project].org
Agreed. There is zero need for a subdomain: this is why CSS exists and has been supported since at least 1998.
Jan 30 2019
Yeah, -03 is uploaded just fine. It's -10 that is still stuck on v2c:
https://commons.wikimedia.org/wiki/File:116th_United_States_Congress_House_Floor_-_2019-01-10.webm still has not been uploaded. It's on the server via v2c.
Jan 29 2019
No, I cannot.
V2C is also stuck on 116th United States Congress House Floor - 2019-01-10.webm. It can do "Downloading to /srv/v2c/output/6e0efd8ec14db8da/dl.unknown_video.part" but it ends up failing because "An exception occurred: TaskError: File already exists. Please choose another name."
This is already done but on video2commons, I tried uploading 116th United States Congress House Floor - 2019-01-10.webm and now I am getting the error message "An exception occurred: TaskError: File already exists. Please choose another name." Can someone fix this?
Jan 28 2019
It failed twice. :/ I guess I am going to use video2commons and then make a Phabricator tag if (when) it fails again. </3
Just received the same error on Commons for File:116th United States Congress House Floor - 2019-01-10.webm. Trying again.
Jan 27 2019
Oh score--looks like it's done. Thanks guys: https://commons.wikimedia.org/wiki/File:116th_United_States_Congress_House_Floor_-_2019-01-03.webm