Adding delivery:partner:wikidata as a secondary wiki prefix style

[GA-Kevin-Codes]

Description

This PR added the key delivery:partner:wikidata to get the same Wikidata rendering as other Wikidata fields by adding delivery:partner to the variable SECONDARY_WIKI_PREFIXES following the precedent of other keys in the list.

[hlfan]

I think before we add keys with only 180 uses and open the flood gates wide we should consider a lookup method that doesn't require all relevant keys being written out.

[GA-Kevin-Codes]

Thanks @hlfan, this was just adding to the existing list, I assume when the list was created there was some discussion on the *:wikidata lookup method. This is only my second PR on the project so I am no historical expert (yet 😉)

[hlfan]

Well, being the one who presumably made you aware of this list, I should probably remember.
I also had to do a little digging with the git blame powered blame view first to stumble on #4401 and #4574, which had much relevant discussion on that matter already.

[GA-Kevin-Codes]

Seems to be a combo of action & documentation. This is documented (see the linked PR in iD tagging schema for a lot more detail) but I am happy if we merge as-is or I can create an issue here to start discussion on a more generic *:wikidata parsing. I didn't see the original reasoning on those PR's but it might just be that originally there wasn't that many Wikidata tags.

[hlfan]

So the assumption that the prefixes need to be accepted dates back to #788, which might not have been necessary at that time already.

[GA-Kevin-Codes]

Great read @hlfan! Seems the low hundreds in usage were what was originally used to fill this list. Concern being if its a catch-all that it would encourage misspellings? Would that not be for the editor to catch, not the website to display?

If so, we can switch line 126 from

elsif key =~ /(#{SECONDARY_WIKI_PREFIXES}):wikidata/o &&

to

elsif key.end_with?(":wikidata") &&

which would still check for Q-ID formatting and semi-colon lists.

[GA-Kevin-Codes]

Looping in @r4f as he has r4f/pull/1 addressing this on his fork of the website.

[hlfan]

The wikidata part of this idea is less of a concern for me than the secondary wikipedia prefixes.

It might be worth removing links for secondary wikipedia secondary language links as they are basically impossible to validate. Otherwise tags like note:wikipedia:en in https://osm.org/relation/1571328 could be misinterpreted easily. @1ec5 what do you think?

[tomhughes]

I think before we add keys with only 180 uses and open the flood gates wide we should consider a lookup method that doesn't require all relevant keys being written out.

All of which is of course why I was against this nonsense in the first place - once you start there's no way to draw a line on what's reasonable and people will keep on wanting it applied to more and more tags.

[GA-Kevin-Codes]

Agreed @tomhughes, I think that's why the discussion pretty quickly turned to editing line 126 from above to capture any tag that ends in :wikidata for processing rather than having to revisit this each time someone has a new secondary Wikidata prefix. Unless you mean the feature itself is not useful, which I would say it is but that of course is a personal determination.

@hlfan, thanks for pointing that out, I think that's what @r4f was trying to address in his fork too but it is much more involved than a single line or 2. Here in the US, we generally discourage Wikipedia tagging in favor of Wikidata so it slips my mind.