Relisting an accessory no longer stops to ask for a clothing size it never had.
A seller reported it of earrings: every relist asked for a size as if the item
were a garment, and the copy that came out was in the right category all along.

The check that asked was reading an answer that does not say what it was taken
to say. GET /api/v2/item_upload/size_groups?catalog_ids[]=<id> replies with the
default size group of the branch the catalog sits in, not with the catalog's own
rule: earrings, necklaces, backpacks and sunglasses under Women all come back
holding the same women's clothing sizes a dress does. So "the catalog offers
sizes" was read as "the catalog demands one", and every accessory without a size
— which is every accessory — was stopped at a window offering S, M and L.

Nothing readable before the publish tells the two apart. What does is the
publish: where a category really requires a size, completion answers
size: Fill in size to continue. That refusal is now what asks.

Fixed
No size prompt for categories that do not want a size. A listing with no
size is taken at its word — Vinted accepted it without one — and the relist
goes through. The prompt still appears before anything is deleted when the
size the listing carries has stopped being valid for its category, which is
the case it was written for.
The prompt moved to where it can be true. If completion refuses over the
size, the size list opens then, the answer goes into the copy held on this
device, and the publish is tried again with an extra attempt so that the
answer is never given to nothing. It is asked once per relist: a second
refusal naming the size means the answer was not the problem. A resume that
ran on its own as a page loaded never opens the window — it records the
refusal and raises the recovery card, and Retry now is what asks.
Backing out of that window keeps Vinted's words on the card. The reason
the card reads back is the refusal itself, not Bumpline's note that no size
was chosen; the note is said in a toast, where it cannot be mistaken for
something Vinted said.

One thing a seller sees is different, and only on Firefox: the rating link now
goes to the add-on's listing rather than to a page that does not exist. The rest
of the release removes the one place the extension wrote markup into a page
instead of building it, and moves the rule that made it safe out of a comment
and into the code.

Mozilla's add-on linter flags an assignment to innerHTML, and it was right to.
Two sentences on the page shown after install carry their own emphasis, a <b>
or an <i> around a button's name, and the loop that drew them handed the line
to innerHTML. The comment above it argued the line could only ever be a
catalogue string written in the repo, because it is fetched with no
substitutions, and said in as many words that a version of that loop passing
substitutions through would break the argument. All of it true, and all of it
kept nowhere but in the comment.

Changed
Emphasis is built rather than assigned. paint() now walks a catalogue
line itself: a <b> or an <i> becomes an element carrying its text, and
everything else becomes text. An unknown tag, a half-open one, a {0} that
was never substituted, an angle bracket a translator typed — each reaches the
page as the characters it is written with, because there is no longer a path
by which it could arrive as anything else. The welcome page draws the same
nodes it drew before, in all three languages.
The build refuses markup paint() cannot draw. A catalogue line carrying
any tag but <b> or <i>, or leaving one of those unclosed, now fails
node build.mjs. The drawing code would have shown a stray <span> as its
own angle brackets mid-paragraph, in one language only, which is the kind of
mistake that reaches a seller rather than a test.
data-i18n-html is now data-i18n-em. The attribute was named after the
mechanism it used, and it no longer uses it. The scan that proves every
data-i18n attribute names a real key learned the new name in the same
commit: had it not, it would have gone on passing while checking two keys
fewer.
Fixed
The Firefox rating link went to a 404. The slug the link is built from
held the add-on's name in the order the name is written,
bumpline-relist-for-vinted, which is not the slug AMO gave the listing. It
is bumpline-vinted-relister, and both were checked against the site: the
old one answers 404 on the listing and on the reviews tab, the new one
answers 200 on both. Chrome was never affected — its id is the one in the
listing URL and has been right since 1.0.0. The comment beside the value
claimed it was empty until there was a listing to point at, which stopped
being true the moment something was typed there; it now says what the three
states are worth, and that a wrong slug is the only one of them that fails in
front of a seller.