Adding shell in case the ability to restrict this is already there.

-shell. You could do some fancy namespace detection parser functions in the Mediawiki: message that detects the category to use. Although that is a bit flaky and broken it appears (Bug 31469)

(In reply to comment #0)

Recently, pages with broken file links are automatically put into
[[Category:Pages with broken file links]]. This would be very useful for
finding image problems in articles, but it is crippled by the large number of
non-content pages polluting the category. The following namespaces should not
be put into this category:

• all talk namespaces - lots of broken image links, mostly due to deleted

images in signatures; fixing them is a huge waste of effort

• Project namespace - used as a talk namespace, so it has the above mentioned

problem (this is Wikipedia-specific, other projects might use their project
namespace in different ways, so maybe there should be a configuration setting
for which namespaces to exempt?)

• User namespace - on many wikis it is conisdered bad manners to make

unrequested changes on someone's user page,

Hmm, i didn't think about talk pages when introducing that feature. Perhaps it should be limited to "content" namespaces (by default? by config?)

(In reply to comment #2)

-shell. You could do some fancy namespace detection parser functions in the
Mediawiki: message that detects the category to use. Although that is a bit
flaky and broken it appears (Bug 31469)

I fixed the issue of parser funcs not working in the message in r107623.

However, using parser funcs there is a hack, and I feel the category should perhaps be restricted further by default, or changed somehow. (maybe 2 different messages, 1 for content namespaces, 1 for not content namespaces, and have the non-content ns message default to '-' (Disabled)? Not really sure.

Is this really needed? We don't do it for any tracking category; tracking those errors is still useful; on en.wiki I see only 6 user pages, a couple dozens on other big wikis.
Perhaps sorting by full page name would help?

That would be because I had the mediawiki message adjusted so that [[Category:Articles_with_missing_files]] contains the articles, [[Category:Templates_with_missing_files]] contains the templates, and the rest just go into the big dump bin that is [[Category:Pages_with_missing_files]] I think this should be closed as WONTFIX as the current behavior is correct.

(In reply to comment #6)

That would be because I had the mediawiki message adjusted so that
[[Category:Articles_with_missing_files]] contains the articles,
[[Category:Templates_with_missing_files]] contains the templates, and the rest
just go into the big dump bin that is [[Category:Pages_with_missing_files]] I
think this should be closed as WONTFIX as the current behavior is correct.

I'm less concerned with Wikipedia and more concerned about the average third-party re-users of MediaWiki (who customize things significantly less). Would the out of the box default behaviour make more sense if these other pages weren't categorized? (/me not really sure). Just because the behaviour is "correct" doesn't necessarily mean its the best possible choice.

(In reply to comment #7)

(In reply to comment #6)

That would be because I had the mediawiki message adjusted so that
[[Category:Articles_with_missing_files]] contains the articles,
[[Category:Templates_with_missing_files]] contains the templates, and the rest
just go into the big dump bin that is [[Category:Pages_with_missing_files]] I
think this should be closed as WONTFIX as the current behavior is correct.

I'm less concerned with Wikipedia and more concerned about the average
third-party re-users of MediaWiki (who customize things significantly less).
Would the out of the box default behaviour make more sense if these other pages
weren't categorized? (/me not really sure). Just because the behaviour is
"correct" doesn't necessarily mean its the best possible choice.

Third-party reusers usually have way less images and pages, are less bureaucratic about deletions hence have less broken links, are less formalist about editing users' pages, have a weaker namespaces segregation etc.
In short, they'd just want an easy way to see all pages with broken file links.

Alrighty, that sounds good enough for me - wontfixing this.

If anyone disagrees (Esp if you happen to be a third party wiki ;) please don't hesitate to re-open.

(In reply to comment #5)

Is this really needed? We don't do it for any tracking category; tracking those
errors is still useful; on en.wiki I see only 6 user pages, a couple dozens on
other big wikis.

Perhaps because enwiki strongly discourages images in user signs, thus user contributions on talk pages don't flood the category when the image in user sign is deleted on Commons.
I hate see my own talk page in a category I cannot put it out from. (Or just with editing other people's undersign.) On the other hand, when the image is missing from a user sign, that is not a real problem that should be treated by all means, especially in archives.
This feature is really useful in articles, but not talk pages.

(In reply to comment #6)

That would be because I had the mediawiki message adjusted so that
[[Category:Articles_with_missing_files]] contains the articles,
[[Category:Templates_with_missing_files]] contains the templates, and the rest
just go into the big dump bin that is [[Category:Pages_with_missing_files]] I
think this should be closed as WONTFIX as the current behavior is correct.

Oh, I see this now! This would be a good intermediate solution, but does not work in huwiki. Ther must be some bug, your links from enwiki look nice, but have a look at [[hu:Kategória:Hibás fájlhivatkozásokat tartalmazó lapok]] where pages from all namespaces are mixed.
I reopen this bug.

Please see https://en.wikipedia.org/wiki/MediaWiki:Broken-file-category and translate to hu correctly and modify https://hu.wikipedia.org/wiki/MediaWiki:Broken-file-category correctly in order to get the behavior that you seek

(In reply to comment #12)
Thanks, it works now! This was a bit hidden functionality. :-)