I have no particular preference on this, but if this is undesirable, we'll need a partial revert of fcf8b631a8f0

I don't think it's a reasonable product ask to allow subtitles to be disabled on a wiki which allows, as that has a discriminatory outcome on users (people without hearing, and those who cannot understand the language of the video as well).

Let's gate it on wgEnableUploads instead?

In T309770#7976419, @Jdforrester-WMF wrote:

Let's gate it on wgEnableUploads instead?

Seems reasonable to me

Change 802537 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/extensions/TimedMediaHandler@master] Only created the TimedText namespace when local uploads are enabled

https://gerrit.wikimedia.org/r/802537

In T309770#7976506, @TheDJ wrote:

In T309770#7976419, @Jdforrester-WMF wrote:

Let's gate it on wgEnableUploads instead?

Seems reasonable to me

I see two caveats here that may be worth considering:

1. wgEnableUploads is enabled fairly widely even on many wikis that effectively don't have an upload link in the sidebar and don't permit non-sysops to upload. These are a number of wikis that once allowed uploads and disable it but keep this flag on to allow admins to theoretically react to anything that might be arise with files that used to exist and e.g. override the handful of files that remain. This means we'd expose the namespace as new and parement entry in every UI control on Search, Move page, etc. but have no practical purpose. This is how the task got filed, and while for wikidata it was always false afaik, many other wikis like nl.wikipedia.org have it technically true via wgEnableUploads => commonsuploads => true and thus remain affected by the regression/bug as reported.

2. We'll need to take into account when disabling wgEnableUploads that this also affects namespaces and thus requires pages to be migrated/renamed etc and might make deleted content inaccessible/un-restorable. This seems fine but something to keep in mind as wgEnableUploads probably isn't expected currently to have that kind of irreversable impact on existing file/timedtext pages.

In T309770#7976890, @Krinkle wrote:

1. wgEnableUploads is enabled fairly widely even on many wikis that effectively don't have an upload link in the sidebar and don't permit non-sysops to upload. These are a number of wikis that once allowed uploads and disable it but keep this flag on to allow admins to theoretically react to anything that might be arise with files that used to exist and e.g. override the handful of files that remain. This means we'd expose the namespace as new and parement entry in every UI control on Search, Move page, etc. but have no practical purpose. This is how the task got filed, and while for wikidata it was always false afaik, many other wikis like nl.wikipedia.org have it technically true via wgEnableUploads => commonsuploads => true and thus remain affected by the regression/bug as reported.

The File namespace is also exposed in places where it isn’t expected to be useful (like as a move target), so I don’t think it would make things substantially worse. However, if there are no actually uploaded video/audio files on the wiki, creating TimedText makes no sense, so maybe it should be disallowed to create subtitles for redlinked files (even on Commons), which would automatically mean that there won’t be any TimedText pages on most wikis.

However, these changes need to be carefully thought over, which means they probably won’t make in this week’s train, so I think the best would be to revert fcf8b631a8f0 partially and 4c147802f2e4 totally now, backport the revert, and then remove the variable in a more thought-over way, without time pressure.

In T309770#7976890, @Krinkle wrote:

In T309770#7976506, @TheDJ wrote:

In T309770#7976419, @Jdforrester-WMF wrote:

Let's gate it on wgEnableUploads instead?

Seems reasonable to me

I see two caveats here that may be worth considering:

1. wgEnableUploads is enabled fairly widely even on many wikis that effectively don't have an upload link in the sidebar and don't permit non-sysops to upload. These are a number of wikis that once allowed uploads and disable it but keep this flag on to allow admins to theoretically react to anything that might be arise with files that used to exist and e.g. override the handful of files that remain. This means we'd expose the namespace as new and parement entry in every UI control on Search, Move page, etc. but have no practical purpose. This is how the task got filed, and while for wikidata it was always false afaik, many other wikis like nl.wikipedia.org have it technically true via wgEnableUploads => commonsuploads => true and thus remain affected by the regression/bug as reported.

Indeed. I consider this very much fixing a bug.

2. We'll need to take into account when disabling wgEnableUploads that this also affects namespaces and thus requires pages to be migrated/renamed etc and might make deleted content inaccessible/un-restorable. This seems fine but something to keep in mind as wgEnableUploads probably isn't expected currently to have that kind of irreversable impact on existing file/timedtext pages.

Yes, though disabling that should be extremely rare anyway.

In T309770#7976920, @Tacsipacsi wrote:

In T309770#7976890, @Krinkle wrote:

1. wgEnableUploads is enabled fairly widely even on many wikis that effectively don't have an upload link in the sidebar and don't permit non-sysops to upload. These are a number of wikis that once allowed uploads and disable it but keep this flag on to allow admins to theoretically react to anything that might be arise with files that used to exist and e.g. override the handful of files that remain. This means we'd expose the namespace as new and parement entry in every UI control on Search, Move page, etc. but have no practical purpose. This is how the task got filed, and while for wikidata it was always false afaik, many other wikis like nl.wikipedia.org have it technically true via wgEnableUploads => commonsuploads => true and thus remain affected by the regression/bug as reported.

The File namespace is also exposed in places where it isn’t expected to be useful (like as a move target), so I don’t think it would make things substantially worse. However, if there are no actually uploaded video/audio files on the wiki, creating TimedText makes no sense, so maybe it should be disallowed to create subtitles for redlinked files (even on Commons), which would automatically mean that there won’t be any TimedText pages on most wikis.

However, these changes need to be carefully thought over, which means they probably won’t make in this week’s train, so I think the best would be to revert fcf8b631a8f0 partially and 4c147802f2e4 totally now, backport the revert, and then remove the variable in a more thought-over way, without time pressure.

I don't agree. This is really quite simple: whilst we still have the broken-by-design model of a TimedText namespace rather than a MCR slot for each subtitle track, the functionality should always be available, unless TMH isn't installed or local uploads aren't allowed. This was an existing bug which is now fixed (except for the minor bug of showing this in a few too many places, because we have the consume and provide parts of TMH intermingled).

It seems that all wikis (except Commons) have this problem?
https://ja.wikipedia.org/w/api.php?action=query&meta=siteinfo&siprop=namespaces&formatversion=2
https://en.wikipedia.org/w/api.php?action=query&meta=siteinfo&siprop=namespaces&formatversion=2
https://zh.wikipedia.org/w/api.php?action=query&meta=siteinfo&siprop=namespaces&formatversion=2
https://species.wikimedia.org/w/api.php?action=query&meta=siteinfo&siprop=namespaces&formatversion=2