💖 Thanks for opening this pull request! 💖

Things that will help get your PR across the finish line:

• Run npm run lint -- --errors locally to catch formatting errors earlier.
• Include tests when adding/changing behavior.
• Include screenshots and animated GIFs whenever possible.

We get a lot of pull requests on this repo, so please be patient and we will get back to you as soon as we can.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.72%. Comparing base (6a5e1ee) to head (4c25de9).
Report is 38 commits behind head on main.

@@            Coverage Diff             @@
##             main    #8513      +/-   ##
==========================================
- Coverage   83.45%   82.72%   -0.73%     
==========================================
  Files         113      113              
  Lines        7596     7596              
  Branches     1827     1827              
==========================================
- Hits         6339     6284      -55     
- Misses       1257     1312      +55     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Thanks for the PR. I asked an Italian colleague about this and he isn't convinced that didascalie is a better translation for the controls. There does seem to be plenty of precedent for sottotitoli per non udenti (in which case we're currently missing the per).

Netflix "Sottotitoli standard e per non udenti"
Disney+ "Sottotitoli, sottotitoli per non udenti"
Youtube "Sottotitoli", "Sottotitoli per non udenti"
Apple TV "sottotitoli e sottotitoli per non udenti"
RAI "sottotitoli per non udenti"

I think it's more important (and more accessible) that the control text makes sense to users than it is that it is a literal translation of "captions" as used in the HTML/WCAG spec. Would didascalie be what users would expect? I also wonder if @astagi has a view on this as the most recent reviewer of the Italian translations.

Similarly, in British English the US English subtitles—captions distinction isn't really idiomatic. Visible text tracks generally are subtitles whether a transcription or translation, and "captions" are subtitles for the hard of hearing when the distinction needs to be made.

Thanks for the PR. I asked an Italian colleague about this and he isn't convinced that didascalie is a better translation for the controls. There does seem to be plenty of precedent for sottotitoli per non udenti (in which case we're currently missing the per).

Hey @mister-ben, thanks for the review and the lengths you went to ensure the quality of the translation, it really warms my heart ❤️

We had a really long internal discussion (hi @Fupete, @astagi 👋) and we settled on that translation as the best option, yet not perfect.

Netflix "Sottotitoli standard e per non udenti" Disney+ "Sottotitoli, sottotitoli per non udenti" Youtube "Sottotitoli", "Sottotitoli per non udenti" Apple TV "sottotitoli e sottotitoli per non udenti" RAI "sottotitoli per non udenti"

I think it's more important (and more accessible) that the control text makes sense to users than it is that it is a literal translation of "captions" as used in the HTML/WCAG spec. Would didascalie be what users would expect? I also wonder if @astagi has a view on this as the most recent reviewer of the Italian translations.

I'm afraid RAI here leads the pack and the others followed, RAI being an authoritative and older institution, but let's just say RAI uhm tends to embrace changes at its own pace.

We can report here all the points of the internal discussion we had - we'd need more time on that to cross-reference everything - but I think the most important point and more quickly explainable is that "non udenti" is an ableist term, defining a person by their lack of hearing. I for one certainly don't think of myself as a "non-chef".

Similarly, in British English the US English subtitles—captions distinction isn't really idiomatic. Visible text tracks generally are subtitles whether a transcription or translation, and "captions" are subtitles for the hard of hearing when the distinction needs to be made.

So, my understanding is that videojs makes that distinction with the kind attribute for the <track> element, and this distinction gets propagated into having two different settings for captions and subtitles. Are we mistaken on that?

Sorry, this fell off my radar. We wouldn't want to have ableist language, if you and your org think this wording is better that's good for me.

Tracks of subtitles and captions kinds get merged into one menu, as that generally makes most sense to users (we used to have a menu for each which wasn't a good UI. For US English and a few other locales the label for the combined settings menu item is (localised) "captions settings", and for other locales (localised) "subtitles settings".

Congrats on merging your first pull request! 🎉🎉🎉