Caveat: The link is added by the FileExporter extension which currently does not have access to FileImporter's configuration.

I only see two horrifying alternatives:

• Make code from FileImporter available to FileExporter, which allows FileExporter to calculate for itself which templates are required.
• Make an API call to commonswiki, which tells us the required templates. Cache locally.

There's an ApiBase#isInternal method we can use to cover ourselves and discourage anyone else from relying on our new endpoint.

Change 533506 had a related patch set uploaded (by Awight; owner: Awight):
[mediawiki/extensions/FileImporter@master] [WIP] API endpoint for CommonsHelper config

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

Change 533524 had a related patch set uploaded (by Awight; owner: Awight):
[mediawiki/extensions/FileExporter@master] [WIP] Disable export if required templates are missing

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

@Rajagum We're hoping to get UX advice for this task. Currently, we're sending users to an unsightly error page, and a high proportion of import attempts result in this error. Alternatives we're looking at:

• Greyed-out tab to prevent export, with a tooltip explaining why this is impossible. We're worried about the tooltip being too small, and cannot include have links.
• Let the button navigate users to the Special:ImportFile page and improve the error text. Maybe it would become a warning dialog.
• As an extreme case, just disappear the button.

Part of the trickiness is that we don't want to show the users *which* templates need to be present, because blindly adding the templates is incorrect.

We're available to chat whenever you are :-D

Happy to look at it this week, most probably on Thursday :)

@Hanna_Petruschat_WMDE

Change 536153 had a related patch set uploaded (by Thiemo Kreuz (WMDE); owner: Thiemo Kreuz (WMDE)):
[mediawiki/extensions/FileImporter@master] Do not track missing license templates as errors

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

With @raja_wmde we collected the following arguments. I hope I did not forget an important one:

• Just removing the button is bad. It leaves the user confused and provides no explanation and no way forward.
• Disabling the button is ok-ish.
• A tooltip probably doesn't provide enough space for all the information we want to give the user (what happened, why, and what's the way forward). A tooltip especially can't contain a link to a help page.
• It could be a popup window or a separate page.
• The help page we want to recommend to the user is probably https://commons.wikimedia.org/wiki/Commons:Licensing or something else on Commons. Commons is where the restriction comes from – not from the source wiki. If this is the case, it makes sense to have the error message presented in the Commons context.
• It's suggested to reword the current message to be more friendly. What happened ("not properly licensed"), why ("Commons requires specific licenses"), and what's the way forward (learn more about licenses on Commons, or ask the Commons community for help).

@thiemowmde very well summarized

Change 533506 abandoned by Awight:
[WIP] API endpoint for CommonsHelper config

Reason:
Changing our approach to this feature.

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

Change 533524 abandoned by Awight:
[WIP] Disable export if required templates are missing

Reason:
Changing our approach to this feature.

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

@thiemowmde Minor detail I wanted to get your opinion about: we could either provide the help page link as a configuration variable, or suggest that on commonswiki the i18n message is overridden using the MediaWiki namespace. I don't like either, though. The configuration variable has no sane default value, and the overridden message makes it impossible to use the translatewiki.net interface to translate, if I understand correctly.

In T228858#5490054, @awight wrote:

we could ... provide the help page link as a configuration variable, [but The] configuration variable has no sane default value

Core's DefaultSettings.php has a few Commons links, such as

$wgRepositoryBaseUrl = 'https://commons.wikimedia.org/wiki/File:';

For a documentation link especially, maybe I was wrong and a public, shared wiki page is justifiable?

@JStrodt_WMDE
Please revise this informational notice text, at your convenience. This is for a warning page thrown by FileImporter when a user imports a file missing an eligible license tag.

This [[SRC_FILE_PATH|file]] cannot be imported because it's not properly licensed for use on TARGET_WIKI.

Read more about licensing on commons to understand whether your file is eligible for import. If you still need help, please visit the community help desk.

The suggestion I currently have in the patch is this:

This file cannot be transferred to $1, because it is not marked with a compatible licence. $1 does not allow such files. This might be resolvable, but most probably means the file is not compatible. Please consult the $2 community policy and talk pages about licensing.

I also suggest to change the other message in an identical way:

This file cannot be transferred to $2, because it is marked as $1. $2 does not allow such files. This might be resolvable, but most probably means the file is not compatible. Please consult the $2 community policy and talk pages about licensing.

[…] or suggest that on commonswiki the i18n message is overridden using the MediaWiki namespace.

I was about to suggest this. But:

[…] the overridden message makes it impossible to use the translatewiki.net interface to translate […]

Excellent point! Can we try to make the link (and only the link) a message? This might look like this: Please consult the [[$3|$2 community policy and talk pages about licensing]]. Here, $3 is a new message that contains nothing but a (local!) link target. This can easily be changed by the community, if needed.

Change 536153 merged by jenkins-bot:
[mediawiki/extensions/FileImporter@master] Present missing/bad license errors as (unfixable) warnings

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

This still needs the default config, currently emits text with a placeholder:

This file cannot be transferred to Wikimedia Commons, because it is not marked with a compatible licence. Wikimedia Commons does not allow such files. This might be resolvable, but most probably means the file is not compatible. Please consult the $2 community policy and talk pages about licensing.

Change 536978 had a related patch set uploaded (by Thiemo Kreuz (WMDE); owner: Thiemo Kreuz (WMDE)):
[mediawiki/extensions/FileImporter@master] Add link to [[Commons:Licensing]] to the relevant warning messages

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

This needs to be deployed Thursday, 19 Sept in order to burn-in before the default deployment.

In T228858#5490395, @thiemowmde wrote:

The suggestion I currently have in the patch is this:

This file cannot be transferred to $1, because it is not marked with a compatible licence. $1 does not allow such files. This might be resolvable, but most probably means the file is not compatible. Please consult the $2 community policy and talk pages about licensing.

I also suggest to change the other message in an identical way:

This file cannot be transferred to $2, because it is marked as $1. $2 does not allow such files. This might be resolvable, but most probably means the file is not compatible. Please consult the $2 community policy and talk pages about licensing.

[…] or suggest that on commonswiki the i18n message is overridden using the MediaWiki namespace.

I was about to suggest this. But:

[…] the overridden message makes it impossible to use the translatewiki.net interface to translate […]

Excellent point! Can we try to make the link (and only the link) a message? This might look like this: Please consult the [[$3|$2 community policy and talk pages about licensing]]. Here, $3 is a new message that contains nothing but a (local!) link target. This can easily be changed by the community, if needed.

Sounds good to me!
Thanks.

@thiemowmde I missed some important details during earlier review of these patches.

• fileimporter-file-missing-required-template is missing documentation for the $2 parameter in qqq.json.
• Same for fileimporter-file-contains-blocked-category-template.
• hasRequiredTemplate throws the exception without including the second parameter, so "$2" appears in the warning text.

@awight, uh, I checked all you listed and I don't think there is an issue. The second message doesn't have a $2.

Change 537454 had a related patch set uploaded (by Thiemo Kreuz (WMDE); owner: Thiemo Kreuz (WMDE)):
[mediawiki/extensions/FileImporter@master] Fix misplaced $2 in a message

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

Change 536978 merged by jenkins-bot:
[mediawiki/extensions/FileImporter@master] Add link to [[Commons:Licensing]] to the relevant warning messages

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

Change 537454 merged by jenkins-bot:
[mediawiki/extensions/FileImporter@master] Fix misplaced $2 in a message

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

I think the last step is to deploy? I'll leave it up to @thiemowmde whether we should backport or let this go out with next Wednesday night's train.

Thanks for the heads up. From my perspective, this is a minor UX improvement, and doesn't justify a backport.

Change 538859 had a related patch set uploaded (by Awight; owner: Thiemo Kreuz (WMDE)):
[mediawiki/extensions/FileImporter@wmf/1.34.0-wmf.23] Fix misplaced $2 in a message

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

Change 538859 abandoned by Awight:
Fix misplaced $2 in a message

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