Page MenuHomePhabricator

Linter fails to detect multiple "upright" parameters as a Bogus file option
Open, MediumPublic


Linter fails to detect duplicate upright parameters like this:

[[File:Temppeliaukio_Church_Interior.JPG|thumb|upright|right|upright=1.15|The [[Temppeliaukio Church]] in Finland is carved out of a single rock.]]

It should see that there are two "upright" parameters and flag them as a Bogus file option.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 13 2019, 8:51 AM

Possibly related: <code>|upright =1.5|</code> (with a space between "upright" and the equals sign) is ignored (the image renders as upright=1.0), but is not detected as a bogus option.

A variant on this bug:

[[File:Temppeliaukio_Church_Interior.JPG|thumb|right|upright=2|upright|The [[Temppeliaukio Church]] in Finland is carved out of a single rock.]]

In this example, the second "upright" is marked as a Linter bogus file option, but it is actually the "upright=2" that is being ignored. The Linter error is correct, but the options are being processed incorrectly (the first valid option should be processed in order to be consistent with handling of the other named parameters like left/right and thumb/frame).

I also documented a bunch of edge cases, some of which behave differently based on which parameter is being processed, at It seems like someone might need to go back to the spec for the File display options and make sure that the code is written to the spec. (...or write a spec...) I keep finding odd little quirks.

ssastry triaged this task as Medium priority.Mar 11 2019, 5:08 PM
ssastry moved this task from Backlog to Parsoid on the MediaWiki-extensions-Linter board.
Jonesey95 added a comment.EditedJan 12 2020, 7:06 AM

One of the notes I added to Help:Images: "If there is a space character between alt and the equals sign, the alt statement will be treated as a caption." This behavior is contrary to how editors are used to working with template parameters. Yes, I know that images are not templates, but it is difficult to manage this inconsistent behavior, and there does not appear to be a good design reason for treating these spaces as syntactically meaningful while (for example) stripping out spaces after the equals sign.

You can see this alt= versus alt = behavior here:

Here is another variant on this bug:

The following image options are not detected as bogus by the Linter engine:

upright 0.75S

In all cases, a caption is present, so the invalid upright option without an equals sign should either be flagged as excess text or as incorrect syntax for the upright option.