refine validating of wikimedia_commons links

[tyrasd]

follow-up to #11499 / #12036:

• show preview of tag upgrades of the validation fix (also for normal website updates)
  
• suggest simplifying full URL to compact wikimedia_commons tag value
  
• improved reference text for image -> wikimedia_commons warning and change to suggestion validation type
  
• fix validation of a few edge cases (e.g. image tag with semicolon separated values, and only a part matches the wikimedia commons syntax; or when wikimedia_commons file name contains % character)
• //edit: also: do not suggest to fix URLs with a domain name without a TLD (see below unexpected fix on the left, and on the right the new behaviour)
  ->

[tyrasd]

PS: @hlfan do you remember the reasoning behind the All split parts valid, but whole value still invalid branch added with #11499? At least now, after tweaking to the isValidURL check, it is not covered by any of our test cases (anymore?) and I cannot think of any way to trigger it. //edit: I removed the branch now in f44ea35, but maybe there is a reason to still have it?

[hlfan]

I think that originated from #11438 (comment). Perhaps @1ec5 can comment on that.

[hlfan]

Maybe there could be a separate message if both the image and the wikimedia_commons keys have valid Wikimedia Commons references because some mappers can't decide what to pick.

[tyrasd]

I think that originated from #11438 (comment). Perhaps @1ec5 can comment on that.

I see, however then this must have been buggy from the start, as !invalidParts.length would not catch the case for an URL like https://example.com/foo;bar (where there is one invalid part).

I guess we could think about how to actually properly handle those cases:

• https://example.com/foo;bar is not currently not auto-fixable as the second part does not look like a valid URL (missing a TLD)
• but https://example.com/foo;bar.png would be interpreted like a two-URL case where the fix would look like https://example.com/foo;https://bar.png. I hope the newly added tag-diff preview will make is obvious that the proposed fix is not to be applied in such cases.
• technically, we could add an extra fix for such cases, e.g. https://example.com/foo;bar.png -> https://example.com/foo%3Bbar.png
• but then it would also show up for https://example.com;example.net as https://example.com%3Bexample.net, which might be confusing if not worded well

[tyrasd]

Maybe there could be a separate message if both the image and the wikimedia_commons keys have valid Wikimedia Commons references because some mappers can't decide what to pick.

Do you mean like in the following example?

wikimedia_commons=File:foo.png
image=File:bar.png

to suggest

wikimedia_commons=File:foo.png;File:bar.png

but as far as I understood the semicolon-is-ambiguous issue is even more pronounced for the wikimedia_commons tag, and should therefore be avoided altogether, isn't it?

[matkoniecz]

wait, is the consensus to fix image=File:bar.png ones?

last time I looked into it (wanted to make a bot edit) there was, sadly, no clear consensus

[matkoniecz]

(and if there is consensus it would make far more sense to run a bot edit rather than asking people to do bot job manually)

[tyrasd]

wait, is the consensus to fix image=File:bar.png ones?

last time I looked into it (wanted to make a bot edit) there was, sadly, no clear consensus

Ooh, I did not know that the image tag also allows wikimedia File:* values:

There are at least three common styles of formatting the link:

• a Wikimedia Commons filename (formatted as File:image.jpg) - although this is commonly tagged as wikimedia_commons=*
• […]

Looks like we should remove that validation until there is consensus about this in the community. Or at least make tweak the wording of the message and use the less aggressive "blue" validation type.

//edit: PS:

(and if there is consensus it would make far more sense to run a bot edit rather than asking people to do bot job manually)

IMHO there is still merit, as this validation would let mappers discover that the tagging should use one tag over the other. In a "magic" bot edit this is not really the case.

[matkoniecz]

Ooh, I did not know that the image tag also allows wikimedia File:* values:

well, there is definitely no consensus for treating it as a valid value

but last time I checked there was no consensus to fix it either

¯\_ (ツ)_/¯

[tyrasd]

I changed the type of the image to wikimedia_commons validation to a suggestion and tweaked the wording slightly such that keeping it remains acceptable, see screenshot in original post.

[hlfan]

A loop with more URLs would be nice to check for percent decoding capability:

https://commons.wikimedia.org/wiki/File:Ajout_noeud_sur_extrimité_ligne.jpg
https://commons.wikimedia.org/wiki/File:Editeur_iD_pour_OSM,_interface_en_français,_juillet_2021.png
https://commons.wikimedia.org/wiki/File:OSM_검토_요청_복사.png