If you want to know, ask.
Oct 15 2023
Sep 18 2023
For what it's worth, this would be valuable to projects like Wikidata and Wikifunctions, where the page model of the vast majority of content is not wikitext, thus making many SpecialPages unusable (e.g. UncategorizedPages on Wikidata).
Aug 21 2023
I'm inclined to say that "more pretty pictures with less text" is superior to "a couple of pretty pictures with some text-dense boxes" so I am inclined to keep the front page more like how it is currently. But that's a weak preference, not a clear must-have. It would be nice if we had some kind of UX testing to confirm "Users can get the information that they need with [Design X] faster than with [Design Y]" or somesuch, but I realize that takes time and money. Maybe a microgrant from the WMF is in order?
Aug 16 2023
Aug 1 2023
Came here from the post on en.wp's Signpost and I have looked over comments here. Is there a way to make an HTTP redirect from "https://mastodon.wikimedia.org/" to "https://wikimedia.social/"? Furthermore, it seems like "https://wikimedia.social/" should be some kind of landing page for any and all social media profiles and a Mastodon instance would be best at "https://mastodon.wikimedia.social/", but I suspect that ship has sailed.
Jul 28 2023
Mar 14 2023
This is not the place to propose a new project: this is the place where we could assign responsibilities once there is a consensus to make a new project. See https://meta.wikimedia.org/wiki/Proposals_for_new_projects to propose a new project.
Feb 21 2023
Both should be closed. Funwormguy1245, this is not a bug.
Both should be closed. Funwormguy1245, this is not a bug.
Dec 31 2022
Aug 22 2022
If you'll see above c. 2020-03-03, this is mostly a matter of doing things like storing interwiki links and making Wikidata-powered infoboxes, not having locally stored databases at Wikispore.
Aug 10 2022
Was this project approved on Meta?
Jun 18 2022
Is this a proposal for a new project? If so, that goes on Meta: https://meta.wikimedia.org/wiki/Proposals_for_new_projects
Jun 8 2022
Dec 31 2021
Made the following because this hasn't been resolved yet: https://phabricator.wikimedia.org/T298406
Oct 30 2021
Just noting that I had a lot of trouble uploading a large file: y2commons didn't work, ChunkedUpload didn't work, publishing from my stash didn't work (a half-dozen times), and one last try at ChunkedUpload/stash failed so badly that the special page for my stash wouldn't load. I have no clue what is up. Another user helped me by uploading the file to en.wp but it needs to be ported over to Commons and overwrite the malformed version there: https://en.wikipedia.org/wiki/File:David_Pakman_talks_to_Rebel_Wisdom_about_politics_and_media.webm
Feb 11 2021
Jan 14 2021
Oh, and thanks, J!
Do I need to remake this ticket every December 31 or will it auto-update? I'm willing to make a calendar reminder for myself.
Jan 11 2021
Dec 11 2020
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