If you want to know, ask.
Sun, Mar 8
Tue, Mar 3
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.
Mon, Mar 2
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
If/when this is uploaded, will it have my username and be added to my watchlist?
Jan 23 2019
What? Why? Is this documented anywhere???
Jan 22 2019
Note that I have begun experimenting with this at test.d and I have my own domain to screw around with this as well.
Jan 20 2019
Second this. test.wikiquote.org would be helpful.
Dec 13 2018
beta.wv shouldn't exist--it's entirely redundant to Incubator. mul.ws actually hosts some multilingual works which makes it inherently different from any other WMF project. Some things will never "graduate" from mul.ws to a new domain so we need to have a method to link to it.
Dec 8 2018
Sure but it can serve as an archive of older files. No one is making new Flash and no one should have made Flash back in the day but preserving some of this content can be valuable.
Nov 29 2018
For the curious, see https://wikisource.org/wiki/Main_Page/Napulitano
Nov 23 2018
Yes, what Candalua said should happen. mul.ws/wiki/foo should redirect to ws/wiki/foo not just the main page.
Nov 10 2018
I don't think anyone at incubator or beta.wv is *opposed* to this.
Oct 14 2018
Aug 28 2018
Aug 25 2018
If there is a standard Names.php deployed to most WMF projects, it would need to be greatly expanded at mul.ws--that is the only project that is intended to host multilingual content (with Commons, Data, and Species being presumably language-agnostic repositories) and that also includes very small languages that will never have content elsewhere. In fact, some of the content there may not be linguistic at all, so we need to have the four special codes listed above and possibly even the private use area to define if that's an option.
Aug 23 2018
Jul 13 2018
Jul 1 2018
Jun 27 2018
It would be nice if it were folded into en.wp for many reasons but I think there is simply too much inertia for that to happen. This task should assume that the third proposal to close it will fail like the first two.