No more discussion, so tacitly, the community is still in favor.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 14 2024
Mar 10 2024
If you use your Wikimedia credentials via OAuth, just see here: https://meta.wikimedia.org/wiki/Global_rename_policy
Jan 22 2024
Jan 21 2024
Dec 31 2023
Yeah, there are definitely different calendars in use around the world, often in tandem with Gregorian, but we don't use any of those for timing when things enter the public domain due to the WMF and its servers being based in the United States.
Pardon me for being so dumb here, but are you talking about words or just the number like "1929"?
Dec 9 2023
This is not a forum for proposing new projects. If you have a new proposal, go to https://meta.wikimedia.org/wiki/Proposals_for_new_projects
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
In T274495#6822572, @Aklapper wrote:This conversation reminds me of discussing the "Export to Excel" button in upstream Phab code in the past - basically https://secure.phabricator.com/T5908#72402.
In T274495#6822569, @Xover wrote:In T274495#6822475, @Koavf wrote:In T274495#6822466, @Xover wrote:Absent specific proposals for better wording
I gave a proposal.
Indeed. But it was [not] specific
In T274495#6822466, @Xover wrote:Absent specific proposals for better wording
In T274495#6822467, @Billinghurst wrote:In T274495#6822445, @Koavf wrote:In T274495#6822219, @Billinghurst wrote:But it is for Kindles. We want to make things as easy as possible for those who just want to download. I reckon just leave it.
There are many devices from many manufacturers that can process this content. Instead of giving an advertisement for a Big Tech abuser, just make it generic. If you have one of their proprietary jails, you know which file types it uses.
Please leave your prejudices at the door.
In T274495#6822219, @Billinghurst wrote:But it is for Kindles. We want to make things as easy as possible for those who just want to download. I reckon just leave it.
In T274495#6822179, @Aklapper wrote:Hi, what is this about specifically? (Please describe what you expect and what happens instead and be specific to avoid misunderstandings.)
./i18n/en.json: "format-mobi": "MOBI (for Kindles)" ? Something else? Thanks. :)
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
In T254646#6262865, @Reedy wrote:In T254646#6262863, @Koavf wrote: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.
There's plenty of tasks with "blacklist" in the title...
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
In T247203#5952250, @Aklapper wrote:Please clarify which specific code hosting you mean when writing "Move all code hosting from GitHub". Or how this relates to Wikimedia Gerrit / Git.
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.
In T228594#5753548, @Xover wrote:@Koavf It's not that simple. Hit me up on my enWS user talk page if you want the nitty gritty details. The short version is that Phe's OCR gadget (which is what this task is about, and which is what I assume you mean by the "default") is based on Tesseract, but that's not where the problem is: it's somewhere in the custom code Phe has written to provide the interface to Tesseract or its interaction with the server infrastructure on Toolforge.
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
In T228594#5749655, @Pols12 wrote:Aklapper had already pointed above a MediaWiki.org link which explains how the Phabricator priority system work: mw:Phabricator/Project_management#Setting_task_priorities.
Phabricator is a tool which allows developers to organize openly their work. They do not have to manage community here. You probably may engage discussions on Meta or on your wiki village pump, eventually pinging a Community Liaisons member to express your priority wishes.
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.
In T228594#5747256, @Jdforrester-WMF wrote:This does not meet the criteria for UBN. Please do not abuse the prioity system.
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.