I'm going to retool this to move the specific alt-text check into our own extension, with a clean hook point in core, as we'd previously discussed. I think this should allow us to piggyback on the lint-time checks more easily without having to put stuff in core parsoid. :D

Updated the Parsoid-side patch in case we do want to make use of it later:

https://github.com/wikimedia/getID3/pull/2 should make 1 mergeable :D i undid my local version of an older fix

RoomEnvironment is relatively foolproof to set up, and will work much better for physically-based rendering (PBR) materials — as frequently found in the glTF format — than point/spot/directional/ambient lighting.

I'll take a peek this week!

(I see this is also in the Hackathon workboard -- perfect timing! I'll have updates on the patch for folks to test by then but I'll be remote for it. :D)

This got brought up recently and I think it's a reasonably self-contained and not huge work blob. :) Adding myself to do a spike test bringing branch up to date and either making it work or deciding we should redo it differently with more resources.

I *would* like do a spike test bringing the gltf branch up to date or replacing it with another renderer... I think it's relatively self-contained compared to other multimedia projects and I may be able to squeeze it into my misc tech debt time budget. ;)

closing as resolved, update should go out with next week's train and start applying on future ffmpeg failures

One additional thing: Safari has native USD model support, depending on whether there are format patent issues or not (needs investigation) it might be worth including support for native display via a conversion. This would be a stretch goal, potentially assignable via Mobile Apps if interested for iOS/iPad/Vision Pro compatibility.

Problem analysis has not changed since my initial reply years ago:

• use GLTF format for color models, it's standard and well supported
• update the frontend and the backend renderers
• if necessary, replace them with newer libraries

Still waiting on WMF to budget time to look into doing more multimedia work. :)

[patch no longer addresses this with a column, separate patch will later in the error string]

This is T358980, will follow up there :)

Agreed that's probably easier and less spammy :) I'll adjust the patch in progress

Ok, the definitions have landed so we can switch them in whenever we get legal approval. The wheels are being set in motion. :)

cf T57942 and T362123

In T362123#9700047, @Ladsgroup wrote:

Yup, we shouldn't use ENUM for schema anymore, just use code constants (missing=0, queued=1, etc.)

Agreed let's do those together...

Confirmed good now. Thanks!

Thanks. Confirmed I'm into the admin interface on new account and can take it from here. :D

Adding this to my list this week. Time to find out and fix ;)

Full non-commons set has been run. It's possible a few bad transcodes remain on Commons (still running some cleanup batches from the audio track bug) so I'll levae this open a tad longer just in case any remaining ones pop up.

enwiki initial low-res batch has completed, i've got a more thorough set running

Haha goddammit I think I see what happened

Being covered on T354502. No need to re-open here, there's no difference between the app and mobile web for this purpose.

Started a batch run for all missing transcodes on enwiki, probably will churn for up to a day (hard to predict timing)

Thanks, it always helps to have specific links. Those are not on Commons, and aren't included in the Commons re-runs (they're on en.wikipedia.org specifically). They should've gotten a batch run before this, but it looks like that didn't happen. I'll add those to the schedule, thanks!

Dropping -cues_to_front 1 into the ffmpeg options should do the job; it'll do a temporary file copy transparently if necessary.

Ended up doing VP9+Opus-flavored HLS for iOS compatibility, expect to make use of this for desktop in future enhancements to do adaptive resolution switching.

this should go out next week, yay!

unclaiming, if anybody wants this cookie. forgot this was on my plate!

general changes done, doing misc backfill for other reasons now :D

Above examples are now working since files were re-run. Thanks for your feedback!

This is confirmed working on iOS 15.8.1 / iPhone SE first-gen and iOS 10.3.3 / iPhone 5S. Could be improved by better codecs (separate issue).

Confirmed working on iOS 15.8.1 (iPhone SE first-gen) in app on [[w:en:Big Buck Bunny]]. If there are specific files still not working, please provide links and reopen.

(Do we.... have a good high-level task for this that covers the conceptual feature for both ios and android and not low-level implementation details? Sounds like we haven't done enough of a public consult on the whole project.)

In T344378#9610271, @Graham87 wrote:

See the comments including mine at: https://en.wikipedia.org/wiki/Wikipedia_talk:Linter#Wikipedia_Mobile_App:_Image_Recommendations_and_New_Lint_Error

Making the default alt text "Refer to caption" or something for thumbnail images (so most images will have alt text) would be a million times more preferable and simpler than this.

In T344378#9611773, @PerfektesChaos wrote:

My comments on mw:Talk:Wikimedia Apps/Team/Android/Image Recommendations were already linked, but I do strongly oppose to make this a LINT nor Growth task.

Some core remarks:

• You need an advanced understanding what blind people or others shall take from a textual or audible image description if they shall really benefit.
• A kind of poetry is necessary: If you close your eyes, then only hearing the description, the image must appear inside your head. When opening the eyes, the same picture shall be visible on the screen. That’s no business for everybody. If no similar image appeared within your mind, the description is waste of time.
• To create a good image description in current context will take five or ten minutes. There is no staff to add this for millions of images.
• We learnt that almost all article authors are creating contra-productive alt= if they are asked to equip images, and they made the situation worse.
• An operational guidance, a cookbook is to be provided first, before pushing people to write alt= texts.
  • In English, some good help is available by associations outside WMF, but I am not aware of any wiki page which is breeding alt= text editors.
  • In German, the external sites did not establish user guidance yet. Some first steps were made, but not sufficient. German Wikipedia is attempting to develop an operational manual, currently on user page level.
• If you clutter many images with not helpful but time consuming bad whaffle-whaffle then blind people and others will switch off image descriptions or stop opening descriptions.
• Many images do not need any description but shall be mute; the existence is to be concealed.

In T344378#9611682, @Jonesey95 wrote:

Using Linter to track missing alt text is a Bad Idea. Missing alt text is not a syntax error. Please learn from your big mistake in the "wide table" Linter tracking fiasco. Linter tracking is for syntax errors that can and should be fixed in all cases; missing alt text, like "wide tables", does not meet any of those criteria.

aaaaaand last items have been run. :D

Should be fully resolved on Commons. I'll do a just-in-case run on affected date range on other wikis.

About halfway through reprocessing on Commons after 24 hours. Expect all affected Commons files re-run within next 24 hours, then I'll run a shorter job fixing up anything affected on other wikis.

[Deployment will remain stalled pending legal approval for MPEG-4 Part 2 Visual video codec. If we get that, it's just a config merge and running the backfill in maintenance; no new development work needed.]

Note there's a possibility people will be too grumbly about adding this to the linter extension in which case we'd do the exact same thing but store it in a similar table with a similar api and a different name. I'd prefer to avoid that though.

General notes based on reviewing Linter API: (https://www.mediawiki.org/wiki/Extension:Linter#API)

The query tweaks didn't really help in practice. Time to add some sensible fixes. ;)

closing as dupe of T358342 (fix deployed, re-running affected files in progress)

Fix deployed, now re-running potentially affected files...

Oof, this is probably a regression from the recent bugfix for streaming tracks. Sorry, likely my fault! I'll double-check the code and see if I did something wrong shortly. If so I can re-run the affected transcodes after fix goes out, sigh...

Also adding this to Wikipedia-iOS-App-Backlog since it affects both mobile web & app views, which is why I'm concentrating on it as low-hanging fruit. If this can go through, video quality on older iOS devices will go up in both. :)

Thx!

Gerrit lets me connect but won't let me push updates to a patchset:

In T358044#9562598, @MoritzMuehlenhoff wrote:

@bvibber Renaming the user name for SSH access will leave files in the old home inacessible (we don't need to explicitly remove these, they will simply vanish over time as we reimage servers). Can you please list the hosts for which you want to retain stuff from the old home? Then we can copy/chown these to the new account name.

In T358044#9562210, @Bugreporter wrote:

Too late now, but Phabricator accounts are easy enough to rename and the linking can be changed from one developer account to another.

Alternatively we can keep the bvibber Phab account as the personal account and rename brion to something like bvibber-wmf so much less disruption will happen in Phabricator.

This will involve:

• Rename brion to bvibber-wmf (or if we want to use bvibber, first rename it to bvibber-personal)
• Move SUL and LDAP linkage from bvibber to bvibber-wmf
• Link bvibber to non-WMF SUL account

Ok confirmed after dancing around the email settings I was able to remove the conflicting one and I now have a working "bvibber" gerrit. :D

Gerrit won't let me remove the LDAP-given email:

Can't log into gerrit with bvibber, it says "Authentication failed."

bvibber LDAP account is, and bvibber phabricator account is now connected to it. I'm not sure if I have any special permissions that need migrating over...