I already moved the repository manually from Diffusion to Wikimedia
GitLab, under my personal namespace (commit 15ade382), but now all
Diffusion tool repos were moved to the toolforge-repos/ namespace
instead. Use that for consistency with other tools; I’ll see if I can
set up the lucaswerkmeister/ version to mirror toolforge-repos/,
otherwise I’ll delete it.

I assume “any” is what I meant here, not “new”.

Also needed to support images with question marks in the title (see
previous commits), though this time it’s the other way around.

Just like the previous commit. (If I hadn’t only noticed this after
deploying the first commit, I would’ve squashed them into one.)

This is needed for files with question marks in the title, e.g.
[[File:CSD Berlin 2022 - Lucas Werkmeister - 49 - Do You Think You’re
More Tired Of The War Than We Are?.jpg]] [1]. Compare also the
corresponding fix to the user script [2].

Note that we don’t need to URL-encode anything for the src attribute: we
got that full URL from the API, MediaWiki is responsible for encoding it
as necessary.

[1]: https://commons.wikimedia.org/wiki/File:CSD_Berlin_2022_-_Lucas_Werkmeister_-_49_-_Do_You_Think_You%E2%80%99re_More_Tired_Of_The_War_Than_We_Are%3F.jpg
[2]: https://commons.wikimedia.org/w/index.php?title=User:Lucas_Werkmeister/wd-image-positions.js&diff=677348415&oldid=653031686

I think :not() has broad enough browser support that we can do this.
(Some more selectors could be combined or simplified using :is(), but I
don’t think that’s sufficiently widely supported yet.)

Bootstrap 5 underlines links by default even if not hovered; for the
depicted links, this is too much, since the underline can obscure other
depicteds or the underlying image. Disable the underline unless the link
is hovered or focused; MediaWiki core’s elements.less (shared by most if
not all skins, I assume) uses the same pseudo-classes.

Put this style in image.css, not depicted.css, as it doesn’t make sense
on-wiki; but add pointers between the two files.

https://getbootstrap.com/docs/5.1/migration/

Someone suggested to use a semi-transparent background instead of an
outline (I’m not sure if they’d want to be named here or not ^^). I’m
not convinced by it, but this changed organization of the CSS (with no
effect) at least makes it easier to try out. Users can add the
background, and potentially remove the outline, in their user CSS, if
they want. (That includes browser extensions like Stylish, or also, for
the user script [1], their common.css on Wikimedia Commons.)

[1]: https://www.wikidata.org/wiki/User:Lucas_Werkmeister/Wikidata_Image_Positions#User_script

Apparently Wikimedia GitLab is considered stable enough for personal
projects like this by now, and getting rid of Diffusion is always a good
thing. Note that we stay on GitHub for CI purposes, at least until
global job runners are available (T297426).

The list of contribution methods in the README can perhaps be removed or
at least abridged later; the main point of the old list was
“Differential is terrible and I prefer literally anything else”, and
with Diffusion gone, that’s no longer a concern, so it’s probably enough
to just let people choose between pull requests on either platform for
themselves (or use the email workflow if they really want to).

Apparently the dependencies vary by Python version; with the
requirements.txt built on Python 3.10, the tests failed on Toolforge
after pip-sync removed importlib_metadata (though they still pass in CI?
no idea why).

Add a code style linter and fix some issues it pointed out. A handful of
rules remain ignored for the time being.

Not really happy with the [i:i + 50] (the more associative operator has
spaces, that’s not nice), but not worth fighting Flake8 over.

Flake8 pointed out the indentation wasn’t consistent.

The previous style was nicely compact, but not worth the Flake8 warning
(or ignore), I’d say.

Flake8 pointed out that the \. was previously an invalid escape
sequence. (It seems to have produced the equivalent of \\., which is
what we wanted, so that’s good.)

Flake8 doesn’t like it, and I can see the reasoning behind it.

Became unused in commit 233eec74.

With all current errors ignored in .flake8. I’ll fix and unignore some
of them in separate commits.

The bad data isn’t necessarily on Wikidata, it might also be on Commons.

Follows-up #5.

This is just slightly nicer than crashing, but still an improvement. I
don’t think more sophisticated support for invalid regions is worth the
development effort. (Treating such qualifiers as if they didn’t exist at
all would be bad, in my opinion, so the “correct” solution should really
show these bad qualifiers to the user and replace them on edit…)

Fixes #5.

This is easier to do and avoids the problem of adding the text node
repeatedly.

This is more discoverable and also more mobile-friendly.

The ability for the user to decline to save only existed in
QuickStatements mode, and the corresponding depicted.remove() call was
removed with the rest of QuickStatements mode in ac82f704.

I want to add “cancel” buttons, so the code apart from checking whether
the keypress was Escape or not will be needed for that too. Extract the
onEscape() handler so we can keep it out of the handler functions.

Also, this made me realize that we’re generally failing to remove the
event handler after successfully editing; fix that.

Some work in progress that I forgot to remove :D

In addition to the previous commit (file URL as input), also support
MediaInfo entity IDs and their URIs in the image title input.

Resolves #3.

Similar as in the previous commit, allow users to paste various URLs
into the image title input and try to parse the ID out of them, for
convenience. This doesn’t support entity ID-based URLs yet, though.

File:Vegetarian Pizza.jpg is an arbitrary featured image with a
reasonably simple title (while still containing a space).

Allow users to paste various URLs into the item ID input and try to
parse the ID out of them, for convenience.

The parsed URL behavior of picking the *last* title from the URL
(query.get('title', [''])[-1]) is meant to match MediaWiki, since that
seems to do the same: www.wikidata.org/w/index.php?title=Q1&title=Q2
shows Q2, not Q1.

“Item ID” is really a misnomer here, because we also support properties,
lexemes, senses and forms (as shown by the previous pattern in the
HTML). However, I don’t have a good alternative term to use here (it
can’t be “entity” because it should not include MediaInfo entities,
which we handle differently), so we leave it at “item” for now. I
suspect, but haven’t thoroughly checked, that most if not all other uses
of the term “item” in the tool also really mean “non-MediaInfo entity”.

Leave a bit of space around the image, so that parts of the user
interface can be visible at the same time: roughly enough space for the
scale slider above and a few depicteds without region below. But on very
small screens, make sure this doesn’t make the max-height negative.

Move the calculation of the wrapper size to the wrapper element’s own
CSS, and inherit it in the img CSS as a variable. This shouldn’t have
any effect yet, but paves the way for tweaking the wrapper size in the
next commit.

Put the image inside a wrapper, and scroll only that wrapper if the
image overflows it, rather than scrolling the whole page. This keeps the
rest of the user interface more accessible.

The CSS needs to be tweaked a little due to the extra element; to make
the hidden buttons work, the wrapper needs to be tagged with the
--active class as well (though we still keep it on the image too).

While this tool initially started as a *viewer* of “relative position
within image” qualifiers, it quickly became an *editor* of this data,
and this may in fact be its primary use now. As such, we should let
users know when they can’t edit, whether that’s because they’re not
logged in and/or because JavaScript is disabled.

The notice is styled like an alert, but doesn’t have role="alert", since
it’s not information that requires the user’s immediate attention (if
users are not interested in editing, they might be okay with seeing this
message on every page view) – I just like Bootstrap’s alert styles
better than the card styles (which would be one alternative).

Note that authentication_area() in app.py takes care to not add a
useless login link when the app doesn’t have OAuth configured, but we
don’t repeat this complexity in the edit_info(); I’m just not very
interested in local development of this tool without OAuth anymore.

I missed this one in ceb0b0cf.

Now that we know the width, remove sizes wider than the actual image
width from the srcset, to keep it shorter and avoid requesting the same
file by different names. Also, if the image width (entry added in the
previous commit) is exactly one of the pre-defined widths (for which see
mainly commit 3fce0034), don’t repeat it, by adding the unique filter.

Now that we have the width (and height) of the file, add it as another
source to the srcset; without this, the full-resolution src doesn’t
always seem to be loaded. (It’s illegal to mix x and w sources in the
same srcset, so specifying just the URL on its own without a width,
which is the same as 1x, would not have been allowed.)

Note that we still use Special:FilePath instead of {{ image_url }} here,
because the srcset must contain PNG or JPEG thumbnails (compare the
comment of ensureImageCroppable() in image.js), whereas the image_url
may use more exotic formats like TIFF.

In practice, I’m not completely happy with what the desktop browsers
I’ve tested (Firefox and Chromium) do with this srcset, but it seems to
be better than before, at least.

Add an additional restriction on the max size of the image: it should
not only be no wider than the page (minus padding), but also no higher
(no padding to be considered on this axis). The scale still applies.

Because calc() can only divide by numbers, i.e. we can’t divide the
var(--width) / var(--height) and have the px cancel each other out, we
need another variable with the numeric ratio. (Could also be two
separate variables, but then the naming of the variables with vs.
without px would become more confusing.) Use this opportunity to also
add another comment listing the available variables more explicitly.

Closes #1.