User Details
- User Since
- Nov 6 2014, 11:07 PM (522 w, 3 d)
- Availability
- Available
- IRC Nick
- Kaldari
- LDAP User
- Kaldari
- MediaWiki User
- Kaldari [ Global Accounts ]
May 16 2024
Jul 31 2023
May 4 2023
Apr 14 2023
@Ladsgroup - Is there any way that folks can manually purge thumbnails that didn't get regenerated (besides reuploading the images)? Apparently action=purge doesn't do the trick. I imagine giving users blanket thumbnail purging capabilities would be a security concern, but maybe if it were limited to their own uploads it would be reasonable.
Apr 8 2023
Folks on Commons are reporting that this is still a problem.
Apr 2 2023
See T192500 for river and island labels.
Just because this work wasn't completed doesn't mean it isn't still a valid bug that needs to be fixed.
Mar 10 2023
people who value free knowledge, free software and privacy are currently left out by WMF microblogging
This is an important point. The very people who already share the WMF's values (and thus would never use Facebook or Twitter), will never see a social media post by the WMF. It might seem like that demographic is too small to matter, but I imagine it overlaps significantly with the demographic of people who would think writing encyclopedia articles in their free time is fun.
@Legoktm - Given that the WMF has no interest in using Mastodon (judging from @LDickinsonWMF's comments and lack of engagement here), I agree that it would make sense for the community to move ahead on this without official WMF support. Do you know anyone in the community (yourself included) that might be interested in such a job? Maybe someone at one of the chapters?
Dec 25 2022
Dec 23 2022
Dec 22 2022
Dec 21 2022
Dec 5 2022
@LDickinsonWMF - Thanks for sharing that information! I'm glad to hear that the WMF is exploring the use of Mastodon and I look forward to seeing what comes out of it.
Nov 26 2022
@Legoktm - That's a good point. For example, Mastodon expects posts to use content warnings and image descriptions for better safety and accessibility. I know Wikidata moved over to your wikis.world server recently. I wonder what their approach is.
Nov 25 2022
@CKoerner_WMF - I heard you might be the person with the WMF Twitter keys, so would love to know your thoughts.
Oct 9 2022
Sep 4 2022
@MarkTraceur @Tgr Could someone with shell access at least look in some of the relevant archive directories and see if anything is in there. Maybe the filenames have been changed or corrupted or it's an encoding issue.
Aug 24 2022
Jul 21 2022
@matmarex - I'm wondering if your change to mediawiki.page.gallery.js from April could have affected this.
@Jdlrobson - Thanks for the response!
Hey @kaldari the issue here is the gallery code has no maintainers so likely nobody is responsible for triaging https://www.mediawiki.org/wiki/Developers/Maintainers
Ah, I should have guessed that :)
I don't know this code, and am not too familiar with how it works in articles, but the content still seems useable. I see the inconsistency but I am not 100% sure why it's a problem to the reading experience. It looks almost like an intended feature to me - adapting to the available space?
Normally the packed mode is supposed to adapt to the available space (up to 1.5X the default height), but if you set an explicit height, it's supposed to restrict it. I concede it's not a major issue for the reading experience, but in principle we're supposed to render the article content as specified by the editors. But I suppose that might be more idealistic than practical.
Jul 20 2022
@Kudpung - If NPP can't clear all new articles within 90 days, I would definitely consider that bankrupt. Despite the number of new articles per day steadily declining over the years, the length of the unpatrolled backlog has only crept longer and longer. It looks like the current backlog stretches at least to January (disregarding converted redirects, moves, undeletions, etc.). What's to prevent the backlog from growing further than 365 days? The idea that it could take a year for a new article on Wikipedia to become truly "live" is disheartening. Sure, it might discourage a few spammers, but it will also surely discourage a large number of good faith contributors. As a long-time leader in the Wikipedia community, I'm sure you understand that and appreciate the implications. And as admirable as your efforts to instill rigor and quality control into NPP have been, it seems apparent that bigger changes are needed than technical band-aids like this. Looking through the older unpatrolled pages, I'm struck by the fact that nearly all of them have actually been reviewed by other editors and cleaned-up or tagged for problems. It's unfortunate that the patrolling process has become largely divorced from this organic decentralized reviewing process. Have you considered ways that these processes could be brought back together? As the failure of Citizendium and similar projects shows us, too much rigor and control kills the power of crowd-sourcing.
@TheresNoTime, @Kudpung - One of the main reasons that a 90 day limit was imposed was to limit the potential for the noindex template feature to be abused. (See lengthy discussion here.) That issue needs to be addressed prior to any changes to the limit. My personal opinion is that the security risk outweighs the risk of non-patrolled articles being indexed by Google (especially since truly problematic new articles such as vandalism or attack pages are typically deleted within a few days of their creation).
Jul 16 2022
@Jdlrobson - I'm wondering if this bug warrants some attention. It affects the display of article content (possibly in all skins) and has been live for 2 months now. I know I'm not helping anything by complaining about it, but I'm surprised it hasn't been triaged yet.
Jul 15 2022
Jun 29 2022
This seems to sometimes affect other skins as well. See, for example:
https://en.wikipedia.org/wiki/Tutelina_harti?safemode=1&useskin=minerva
https://en.wikipedia.org/wiki/Tutelina_harti?safemode=1&useskin=vector
The images all initially load at the correct size (height 150), but then some of them are dynamically resized to a larger size, sometimes reflowing the page. If you resize the window, the images randomly change sizes as you are resizing, leading me to believe that this bug is likely related to responsive skin code.
May 19 2022
I have confirmed this bug on English Wikipedia in both Chrome and Safari. As it affects the presentation of article content, it should be considered high priority.
Apr 2 2022
What I would like to see is a very small speaker icon, not a play icon (which is ambiguous in this context), which when clicked, opens a modal or floating player (which includes a link to the file page). So something very similar to what you see in the first sentence of https://en.wikipedia.org/wiki/France, but opening a player instead of linking directly to the audio.
Mar 29 2022
Mar 24 2022
Mar 19 2022
An average Wikipedia reader is not going to have any idea what a tiny Commons logo means, but they will have some idea what the information icon is for, even if they don't expect it to take them to Commons. Either way, something like T258585 seems like a better solution in the long term.
Jan 2 2022
Is this still a valid feature request? The main problem identified in the description (that some articles are linked to in Wikidata via redirects) doesn't seem to actually be a problem, as this is explicitly allowed on Wikidata, and desirable in many situations. If the feature request is just to remove unintentional links via redirects, that should be clarified in the title and description.
Jun 25 2021
Jun 8 2021
May 26 2021
Apr 23 2021
Apr 21 2021
Reopening as the list is again out of date. See also T280829.
Apr 20 2021
Apr 19 2021
@Izno - I'm not arguing against Citoid doing sanitation of the date. I just think the Citoid service should sanitize it to YYYY-MM, not YYYY-MM-XX for three reasons:
- EDTF is too new and I don't know a single browser that supports it yet (via JS).
- All 20 versions of RefToolbar handle YYYY-MM fine. YYYY-MM-XX breaks them.
- As stjn mentioned, the #time parser function also doesn't support YYYY-MM-XX (although I'm not sure what that impacts).
While I understand that the idea of fixing the problem from the VisualEditor side (either with '-XX' or full internationalization) may feel like throwing a request into a black hole, I'm pretty confident that @Mvolz could handle it, and I'm curious to get her opinion on that idea.
@Mvolz - For the short term, what do you think about moving the '-XX' addition from the Citoid service to the Citoid extension (i.e. VisualEditor)? Otherwise, we need to fix RefToolbar on all the wikis ASAP per https://en.wikipedia.org/w/index.php?search=%22undefined+NaN%22&title=Special%3ASearch&go=Go&ns0=1 (which I can't do since I don't have permissions).
@Izno - As I mentioned above, the Citoid service never interacts directly with English Wikipedia, so that's not a reason for Citoid to not use 2020-12. Accommodation of CS1 (and any potential localization) should happen at the VisualEditor/RefToolbar level, not at the service level.
I... guess? That's like saying Wikipedia doesn't have a white background: it doesn't (pretty sure it's not #fff but I've haven't checked lately), but no-one cares because the end effect is that some systems mostly-powered by Citoid do. Either Citoid does the work or the other systems do.
@stjn - Sorry, that makes sense!
@Mvolz - Also here is my opinion on what the correct solution to the original problem is:
- Have Citoid return all dates in regular ISO 8601 format, e.g. 2020-12 for December 2020.
- Have VisualEditor convert the date into a standard JavaScript date object, e.g. new Date('2020-12'), which unlike CS1 does adhere to ISO 8601 AFAICT.
- Have VisualEditor convert the JavaScript date object into a localized date for that wiki (which should be relatively easy since it has access to all the local MediaWiki JavaScript functions).
I'm not sure why everyone in this Phabricator discussion is thinking that Citoid interacts directly with CS1 as that isn't true.
I'll try to fix the RefToolbar code (for the Wikitext 2010 editor) later today...
Apr 18 2021
Note that Source Han Sans is licensed under the SIL Open Font License.
Apr 14 2021
Mar 14 2021
This task seems to be getting more complex by the day. I wonder if it might be better to just keep it simple and disable the download button for disambiguation pages, as that case is unambiguously needed. This could be done with the existing __DISAMBIG__ magic word via a hook handler in the Disambiguator extension. I would hate to see a solution that creates a lot more curation work for Wikisource, as en.wikisource (at least) already has lots of curation backlogs. Just some thoughts to consider.
Feb 19 2021
Feb 8 2021
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/602422/ still seems like a product decision by @Lydia_Pintscher and or @Samantha_Alipio_WMDE that needs to happen here.
In that case, would you mind asking one of them to respond here or at T54564? They do not seem to be responsive to Phabricator pings.
Looking at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/602422 this changes all input of site title to NOT be normalized.
This will probably lead to a large number of sitelinks being created as redirects, rather than just for the cases discussed here and in T54564 etc.
That is correct.
Briefly looking at T235420#5932084 it sounds like this could have a solution that doesn't change all sitelink title input.
This comment suggests that the issue is that badges can not be created on sitelinks that are redirects.
Is that functionality alone enough to meet the requirements here?
This ticket is after all about "Create wikidata badges to indicate when sitelinks point to Wikipedia redirect pages", not "do not use canonical pages names (including following redirects) when sitelinks are created"
Either solution is fine with me, but just ignoring everyone isn't a good solution. The Wikidata community clearly favors allowing redirects as sitelinks and has been doing it via a workaround for a long time now. There's no good reason (that I've heard) to make it difficult.
Jan 26 2021
If there are no objections within the next two weeks, I'm planning on +2ing https://gerrit.wikimedia.org/r/602412 and https://gerrit.wikimedia.org/r/602422.
Dec 26 2020
Dec 25 2020
Oops, my CSS is missing a space!
Dec 23 2020
Observations by the end of November 2020
After turning off IP editing on ptwiki, we saw:
- an increase in active registered editors
- an increase in new accounts
- an decrease in total edits
- an decrease in reverts
- an decrease in non-reverted edits
- an decrease in blocks
However, the ORES model is known for being biased against IP editors.
@jwang - This seems like an extremely important detail. Can you elaborate on it? I skimmed through the paper you cited, but didn't see anything about it.
Dec 22 2020
I changed it to "Dankeschön senden (für andere sichtbar)?" which is 19 characters shorter.
Maybe the real problem here is just that the string in German is way too long.
@Addshore - Both Amir and myself have tried to ping @Lydia_Pintscher by Phabricator and email several times over the last six months to see if she had any remaining objections to merging https://gerrit.wikimedia.org/r/602412 and https://gerrit.wikimedia.org/r/602422. Neither of us have heard back, so I'm going to assume that silence means consent in this context. Unless you know something that we don't, it seems like we should move ahead with these patches, as there is community consensus in favor of this approach. (See RFC and Wishlist proposal.) As I mentioned above, it seems like Lydia's previous objections have been resolved by the redirect badge and templates like {{Wikidata redirect}}. What do you think?
Dec 21 2020
@matthiasmullie - Thanks for the thorough investigation! Yeah, it sounds like we should revisit this once it is decided how MediaSearch will be utilized on Commons. Depending on how that goes, it may make sense to just drop the depicts auto-suggestions.
Dec 16 2020
@matthiasmullie - Which code repo actually controls this feature? Is it a hook in WikibaseMediaInfo or something implemented directly in CirrusSearch or something else?
Dec 15 2020
Fixed. You can see the new version of the button in action at https://test.wikipedia.org/wiki/User:Kaldari.
Dec 14 2020
A new test using Test OCR document 2.jpg
Engine | Formatting Errors | Character Errors | Whitespace Errors | Curly Quotes Preserved | Other Notes |
Tesseract 4.1.1 | none | 15 | 0 | yes | 'Lancaster.'→'———', 'I should'→'1 sheuld', period changed to comma, 'a'→'a_', 'negro'→'necro' |
Tesseract 4.1.1 (eng+Latin) | none | 13 | 1 | yes | 'Lancaster.'→'enge', 'I should'→'1 sheuld', period changed to comma |
Google OCR (English) | none | 3 | 0 | no | 'I' deleted, 'inflict'→'indlict', em dash changed to space |
Indic OCR | none | 1 | 0 | no | em dash changed to hyphen |
''Character Errors" means errors other than not detecting diacritics or curly quotes.
@Samwilson @aezell - Now that we have Tesseract 4.1.1 on Toolforge, I went back and tested with it. Interestingly, the accuracy was greatly improved by specifying the languages to apply (even for the English part), suggesting to me that Tesseract doesn't have good language detection (a problem that merlijn.wajer at the Internet Archive is apparently working on).
Engine | Formatting Errors | Character Errors | Whitespace Errors | Diacritics Preserved | Curly Quotes Preserved | Other Notes |
Internet Archive | none | 4 | 0 | no | yes | confused by opening caps and ç, converted most diacritics to correct character without diacritics |
Internet Archive (French) | none | 11 | 0 | yes | yes | confused by opening caps, changed w to m, changed ; to j , changed l to i, etc. |
Tesseract 4.0.0-beta.1 | none | 8 | 1 | only é | yes | "Alice"→"Aitice", changed l’ to P, confused by diacritics other than é |
Tesseract 4.1.1 | none | 13 | 1 | only é | yes | "Alice"→"Aitice", all other errors in the French part |
Tesseract 4.1.1 (eng+fra+Latin) | none | 2 | 1 | yes | yes | 2 apostrophes missing in the French part |
Google OCR (English) | extensive errors | 0 | 2 | yes | sometimes | no paragraph breaks, only line breaks |
Indic OCR | none | 2 | 4 | yes | sometimes | changed ? into ., omitted a quotation mark |
''Character Errors" means errors other than not detecting diacritics or curly quotes.
Test file: Test OCR document.jpg
Dec 10 2020
For future reference, here are some ways to check if pages are disambiguation pages on save...
@Xover - Have you tried it with a newly uploaded file? That should let us know if it's a caching issue or just not working at all.
I think we should push out a MediaWiki-wide fix for this ASAP. TagItemWidget is prominently used in the Preferences interface, the Search interface, in ContentTranslation, UploadWizard, etc. Once this hits Wikipedia, a lot of people are going to notice.
Rather, I think the focus on the IP information is a bit too short-term and is a distraction from the issue that really we just have very bad counter-vandalism tooling as soon as someone signs up. This is a problem today as well. I think it's worth focussing on that and exploring more the space of how we can empower patrollers and admins to do more with less.
@Krinkle - That's exactly what the Anti-Harassment Tools team is working on. You can read more about it at https://meta.wikimedia.org/wiki/IP_Editing:_Privacy_Enhancement_and_Abuse_Mitigation#Tools and https://meta.wikimedia.org/wiki/IP_Editing:_Privacy_Enhancement_and_Abuse_Mitigation/Improving_tools.
Instead of a cloak flag what if it was just a new user right (e.g. hide-ips) that could be assigned to any user group, like extended confirmed users? That way each wiki could tailor it to their specific anti-vandalism needs and capacities.
Dec 9 2020
I've updated the Developers/Maintainers list.