User Details
- User Since
- Nov 6 2014, 11:07 PM (398 w, 3 d)
- Availability
- Available
- IRC Nick
- Kaldari
- LDAP User
- Kaldari
- MediaWiki User
- Kaldari [ Global Accounts ]
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.
I approve as well in case it matters ;)
Note that this has been made into a proposal at the Community Wishlist Survey: https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2021/Wikidata/Link_Wikipedia_redirects_to_Wikidata_items
We’ve actually wanted to do this from the start, but have not pursued this because of the dual licensing.
The licensing is not an issue for any data that would be automatically filled in by UploadWizard. None of that data is copyrightable. Bots have been adding this data from the template content since at least January 2020 with no controversy.
Dec 8 2020
Dec 7 2020
@Iniquity - If you expect anyone to work on this bug, you need to provide some specifics. When you say "The player's launch buttons are slightly not adapted to the accessibility recommendations" what are you actually talking about specifically?
Note that this is a cosmetic issue as the buttons are still clickable and functional.
@WDoranWMF @AMooney - This was being worked on by a volunteer a year ago, but never made it through code review and is now stalled. At the very least we are going to need CheckUser to use the actor table in order to move forward with IP masking. Is this something that Core Platform could pick up and carry across the finish line?
Dec 4 2020
@kchapman - This was being worked on by a volunteer a year ago, but never made it through code review and is now stalled. At the very least we are going to need CheckUser to use the actor table in order to move forward with IP masking. Is this something that Core Platform could pick up and carry across the finish line?
Dec 3 2020
I would strongly favor full extension of externalLinks.json via a page like Mediawiki:KartographerExternalLinks.js. There's nothing wrong with doing this, especially now that the MediaWiki namespace is locked-down to a very small number of editors. Other MediaWiki extensions and services allow similar on-wiki configuration (e.g. WikiLove, PageCuration, Citoid, etc.).
Dec 2 2020
@sdkim - Would love to learn more about this task.
Note that the LandingCheck extension only does its own geolocation lookup as a fallback (if Geo.country was not passed to it within the link).
Nov 19 2020
Nov 9 2020
@Xover - What would be the effect of just deleting all the caches? Tesseract has been upgraded since most of those caches were generated anyway.
Nov 4 2020
Just to give some context, AntiSpoof has two main use cases (which don't always align perfectly well):
Nov 2 2020
Oct 29 2020
Oct 28 2020
Yes, since this feature has already been implemented and deployed (although not to the bigger Wikipedias yet), I think we can close the RFC. See https://meta.wikimedia.org/wiki/Community_Tech/Watchlist_Expiry and Expiring-Watchlist-Items for further updates.
Oct 27 2020
@Ammarpad - Ah, that makes sense! Thanks for clearing up the mystery!