Community Wishlist Survey 2021/Multimedia and Commons/Make File syntax processing match the specification and documentation
The survey has concluded. Here are the results!
- Problem: File: syntax as described at mw:Help:Images is inconsistent and does not work as expected in all cases. Linter fails to identify all problem cases. The "parameters" (for lack of a better word) and options used in the File: syntax do not work in a predictable, consistent way, and their implementation is inconsistent with how template parameters work.
- Who would benefit: Editors who add multimedia files to pages on all MediaWiki sites would experience more consistent results that are in line with the documentation and the editors' experience with template use.
- Proposed solution:
- I think that the entire File: syntax specification, if there is one, needs to be checked and adjusted to deal with the problems detailed in the various phabricator tickets linked below.
- Then the MediaWiki File: handling code needs to be adjusted to match the specification.
- Once that is done, the documentation needs to be adjusted to match the new specification.
- As part of the code update, Linter needs to be adjusted to detect additional errors and to stop reporting false positives.
- I am open to other solutions, but there is so much inconsistency that I think a thorough checkup is needed.
- More comments: Note that many of the phabricator bugs linked below are characterized as Linter errors, but some of them identify situations in which an editor would reasonably, based on the documentation and similar syntax in other realms (e.g. templates) expect a certain behavior, and the File: renderer does not meet that expectation.
- Phabricator tickets:
- task T216566: Capitalized versions of valid File options are usually (but not always) ignored, but are (usually but not always) not flagged as Linter bogus file options.
- task T216003: Linter fails to detect multiple "upright" parameters as a Bogus file option (there are multiple variants within this bug report, including inconsistent handling of spaces before and after equals signs in File: parameters. Note also that if there is a space character between alt and the equals sign, the alt statement will be treated as a caption.)
- task T215999: Linter does not detect invalid "500px500px" as a bogus file option (also "600 px", "left150px", duplicated "300px")
- task T179605: LintError bogus-image-options triggers on "Thumbtime" (in general, case sensitivity works inconsistently in File: syntax)
- task T266406: Linter false positive: "Center/Left/Right" as caption for gallery image (no workaround is available)
- task T264464: Conflicting border/thumb/frame options are not detected as Linter errors (Until October 2020, mw:Help:Images said "If multiple of these options are present, only the first one will be used". That statement was incorrect, in that some options have priority over others regardless of position, leading to inconsistent results for editors and readers.)
- Proposer: Jonesey95 (talk) 22:00, 16 November 2020 (UTC)
thumb in gallery bug
I would like to add one more Linter bug I have noticed. Most of the times it does not count thumb within the gallery tag as a bogus file option, even though thumb is invalid in gallery. en: H:GT AVSmalnad77 chat 08:58, 14 December 2020 (UTC)
- Support as proposer. Jonesey95 (talk) 23:16, 8 December 2020 (UTC)
- Support Anything that brings consistency and predictability to File: options and hunting for lint errors gets my vote. Both of these areas have learning curves in places they shouldn't. Pauli133 (talk) 17:25, 9 December 2020 (UTC)
- Support Ciao • Bestoernesto • ✉ 02:45, 10 December 2020 (UTC)
- Support Libcub (talk) 20:04, 10 December 2020 (UTC)
- Support As someone who cleans Lint errors in multiple language Wikipedias, I support any improvements to the Lint error detection system. AVSmalnad77 chat 08:43, 14 December 2020 (UTC)