Template talk:Tag

From OpenStreetMap Wiki
Jump to navigation Jump to search

Discuss Template:Tag here:

spurious space before subkeys

Does anybody else notice a spurious space in addr:street=*? Ipofanes 05:55, 14 November 2009 (UTC)

I have corrected it.--Nazotoko 19:49, 3 December 2009 (UTC)

values verses variables

I'm trying to use this template (because it's nice to be consistent) I'd like to distinguish between two cases - when you want to state a possible value for the tag, and when you want to indicate the value is variable. Maybe an example:

  • ncn = yes
  • ncn_ref = number

i.e. I expect the letters y, e and s to go into the database, but not the letters n, u, m, b, e, r.

Can we accomodate this in this template? I'll keep using italics and similar bodges if not, but it might be worth someone investigating. Gravitystorm 20:47, 30 December 2007 (UTC)

As per discussion below, you can now control the linking as follows:
ncn=yes ...with both key and value linkified is achieved with this syntax: {{Tag|ncn|yes}}
ncn=number ...with only the key linkified is achieved with this syntax: {{Tag|ncn||number}} (with an extra pipe '|' char)
-- Harry Wood 10:02, 4 March 2009 (UTC)

Link to value page too?

At the moment, this template links to the tag's page. e.g., if you do {{Tag|highway|motorway}}, the highway part of the highway=motorway links to Key:highway. Would it not make sense to link the motorway part to the relevant page (Tag:highway=motorway) too? Something like [[Key:{{{1}}}|{{{1}}}]]={{#if:{{{2|}}}|[[Tag:{{{1}}}={{{2}}}|{{{2}}}]]|<nowiki>*}}</nowiki> would do it (see Template:Tag_test). If the second argument (the tag value) is given, it will link to it, otherwise it will just provide a link to the key page and show =*. See my user page User:Milliams for examples. Any complaints or should I make the change? --Milliams 18:55, 6 January 2008 (UTC)

I think this is a good idea.--Etric Celine 18:57, 6 January 2008 (UTC)
I'm glad you think so. It wouldn't be possible without the huge amount of effort you've recently put in into moving all the pages to sensible places. Thankyou :) --Milliams 19:04, 6 January 2008 (UTC)

Having though about it, I realised I wasn't catering for the case where you want to have something like bridge=yes. That would try to link to Tag:bridge=yes which of course is never going to exist. To get around this, I've added (to Template:Tag_test) the ability to do {{Tag_test|bridge||yes}} or {{Tag_test|ref||''ref number''}}. If you skip the second argument, you can pass a third argument which will display in plain text. Does this seem like a good way to do it? --Milliams 19:54, 6 January 2008 (UTC)

You are right, this might be a problem.
It is possible to catch yes/no/true/false and numbers for example with some parser functions. I've done it for the KeyValue and TagValue templates.
But this won't work for name=Bremen or ref=B23 and so on.
I think your solution should work a lot better, but could lead to misinterpretation for wiki newbies. Nonetheless lets try it your way, we can still tidy up if someone use it in a wrong way or just live with a few wrong and non existing links. :)
--Etric Celine 23:33, 6 January 2008 (UTC)
I've made the change and am about to go cleaning up any mess it caused :P I've put usage information on the template's page to try to reduce any confusion. --Milliams 12:30, 7 January 2008 (UTC)

Changing link destination

Would it make more sense to link to a section of the Key: page, so that e.g. highway=motorway links to Key:highway#motorway? --Hawke 17:08, 29 January 2008 (UTC)

Related is the idea to change the link of the Value part. Like bicycle=* should really link to Key:access#Transport_mode_restrictions:. Elrond 19:48, 4 March 2008 (UTC)

I'd say that both ideas should be done via #REDIRECT [[page#anchor]] (e.g. #REDIRECT [[Key:highway#motorway]], Key:bicycle containing #REDIRECT [[Key:access#Transport_mode_restrictions]]). I did this on bicycle=* as a test. Feel free to apply it to other Tag pages as well. -- MapFlea 16:08, 6 November 2008 (UTC)

Supporting Language Namespaces

Hi all, I noticed a discussion on the German Tag template whether or not it may be possible to check the presence of a DE article and automatically point to the English one if the German one doesn't extist (with #ifexist). What I'm wondering now is whether or not it may be possible to use this #ifexist function together with the page's namespace. Like (pseudo code) {{#ifexist {{NAMESPACE}}:Key:{{{1}}}|=[[{{NAMESPACE}}:Key:{{{1}}}|{{{1}}}]]|=[[Key:{{{1}}}|{{{1}}}]]}} … (I don't know if this code would work at all, so please really treat it as pseudo code). If it works, it could replace all language-specific Templates and still leave the user in the same language he's currently reading. -- MapFlea 10:06, 7 November 2008 (UTC)

It's done! I used Template:Key as a play ground (can someone delete it, please?) to keep the history clean and added language namespace support now. It will default to both the English (i.e. non-language-namespaced) version of Key and of Tag articles. Please spread the word! -- MapFlea 08:20, 12 November 2008 (UTC)
ok I've deleted Template:Key -- Harry Wood 10:55, 13 November 2008 (UTC)
Do you think that it should be emphasized when we link to the default (English) version of an article because there's no one in the current namespace, e.g. by using (en) (only touching namespaces other than the main one)? -- MapFlea 07:26, 13 November 2008 (UTC)

So, this doesn't work anymore? --Driver2 23:18, 23 January 2009 (UTC)

How does it work?? (the link to highway=bus_stop doesn't link to DE:Tag:highway=bus stop on DE:Tag:amenity=bus station ...) -- Schusch 21:32, 3 March 2009 (UTC)

please explain it at least in short words - does the language support normally work with this template (but works for the moment not because of technical reasons?) -- Schusch 13:24, 4 March 2009 (UTC)

The usable number of #ifexist are limited to be less than one hundred in a page. We need to avoid to use it if we can. How's it? [[{{{kl|}}}:Key:{{{1}}}|{{{1}}}]]{{#if:{{{2|}}}|=[[{{{vl|}}}:Tag:{{{1}}}={{{2}}}{{!}}{{{2}}}]]|={{{3|*}}}}} with additional parameters, kl (key's language) and vl (value's language). For example, {{Tag|kl=DE|highway|motorway}} will make links to DE:KEY:highway and Tag:highway=motorway. --Nazotoko 20:36, 30 August 2009 (UTC)

I have tested it at Template:Tag test. It looks working well. I am going to apply it to this template. --Nazotoko 02:49, 2 September 2009 (UTC)

Performance problems

We get "Warning: This page contains too many expensive parser function calls." on many pages because of the if-function used in this template.
Since several pages include this template more than hundred times it needs to be kept simple!
--Phobie 15:11, 3 December 2008 (UTC)

Yeah the auto-generated Category:Pages with too many expensive parser function calls must be a new feature of parser functions. That category had many more pages yesterday so I guess your edit yesterday remedied the situation. But the language support discussed above, is disabled now hey?
I'm not sure whether or not the efficiency of parser functions is anything to do with the wiki outages we've been having. Guess it doesn't help though.
-- Harry Wood 10:07, 4 December 2008 (UTC)

Always render left-to-right

I think it makes sense to always render this in left-to-right order (key on the left, value on the right) even when used on right-to-left pages. To do this a dir="ltr" attribute would have to be added to the tt tag. --Lyx 11:29, 3 October 2009 (UTC)

As there are apparently no objections, I have now added the dir attribute
-- Lyx 20:34, 9 October 2009 (UTC)

State of language support

Will the language support be restored at all? When it was introduced, we replaced all uses of Template:De:Tag with this template and deleted the language-specific template, which means that all tag links currently send the user to the English page. Should Template:De:Tag be undeleted and put back into use? The kl/vl parameters aren't really a useable solution. --Tordanik 15:59, 19 October 2009 (UTC)

I am the person who made the kl/vl parameters. I know that there was Template:De:Tag and it linked DE: pages for both key and value. My suggesting solution is rebuilding Template:De:Tag as an alias of Template:Tag. Write it as {{Tag|subkey={{{subkey|}}}|kl=DE|vl=DE|{{{1}}}|{{{2|}}}|{{{3|}}}|{{{4|}}}}}. But before to do so, it is better to discuss the parson suggesting to delete the template. Otherwise, the rebuilded alias template will be deleted again. --Nazotoko 19:16, 3 December 2009 (UTC)

Bug in the subkey syntax

The syntaxes {{Tag|key|value|subkey=subkey}} {{Tag|key|:=subkey|value}} aren't working properly. The ":" in the #if makes an indentation, I have tried to debug it using the nowiki command, but the wikilink still doesn't work. --Gwilbor 18:15, 19 February 2010 (UTC)

lists of values

Resolved: added 2 values --MasiMaster 23:39, 19 January 2012 (UTC)

Hi, can we extend the template to deal with multiple values please? e.g. my=val1;val2 to embedd 2 links to the specific feature pages? --!i! 18:56, 11 August 2010 (BST)

+1 - needed frequently. axk 17:50, 25 November 2010 (UTC)
+1 - same also for key=value1/value2 --Skippern 18:11, 25 November 2010 (UTC)
Really is it needed frequently? See ^^#Performance problems^^ -- Harry Wood 18:42, 25 November 2010 (UTC)
ohh, i read this page after i add some new features. this is now included: {{tag|motor_vehicle|agriculture|;=forestry|vl=XY|vl2=YX}} -- MasiMaster 23:39, 19 January 2012 (UTC)

I think semicolons should be used to represent the multiple values within a field, not alternative values. For that, I've seen some people (specially in proposals) using a slash. A slash also has that meaning in name=* with multiple values, such as in shared boundary features.--Fernando Trebien (talk) 13:29, 16 February 2017 (UTC)

Whitespace handling

Very long descriptive tag values such as the one on Key:description break quite horribly with white-space:pre. On a small screen, the long, unbreakable line for description= drops all the way down to after the green float, which means it ends up after the fold and breaks up the example. Not the best way of explaining how the description tag is supposed to work.

Is anyone actually bothered about collapsing whitespace in the value part of the tag? I'll assume not and make the appropriate changes. We can't use white-space:pre-wrap if we want browser compatibility, sadly.

--achadwick 13:18, 30 September 2010 (BST)

Third param wiki interpretation

The third parameter (an unlinked value) allows wikicode, so you can do things like this:

Code Rendering Comment
{{tag|width||''numerical value''}}
width=numerical value Wiki-italics are pretty common here

It can have unintended side effects though:

Code Rendering Comment
width=# # interpreted as ordered list
width=* * interpreted as unordered list
(this style is unnecessary anyway -- just ditch the last 2 params)

I saw this problem earlier on one page. It might not come up often enough to deal with. Mrwojo (talk) 01:52, 23 March 2013 (UTC)

You can use <#> or [#] instead # : shop=[#]. <>|[] will mean that it is not a value, but the pattern --dr&mx (talk) 07:54, 23 March 2013 (UTC)
Making it <*> by default is unnecessary, in my opinion. Mrwojo (talk) 19:38, 23 March 2013 (UTC)
Same opinion here. I will revert this change. @dr&mx: Please discuss such a change on a broader base. --Andi 20:56, 23 March 2013 (UTC)

You can also use

Code Rendering

--Andi 10:23, 23 March 2013 (UTC)

It looks like you can also use the above trick for tags where the value contains the | character itself, what would otherwise break the macro, e.g.

Code Rendering

--User:Aceman444 19:28, 30 Dec 2013 (UTC)

Wikipedia/Wikidata links for empty values

The recently added feature for creating links if the value is a Wikipedia or Wikidata link breaks when there is only one parameter, like this:

In my opinion it should just display the usual =* without any link. --Tordanik 19:00, 10 May 2014 (UTC)

Is there any reason behind why this template doesn't work in language namespaces?

Is there any reason why translators must use Template:DE:Tag vs Template:RU:Tag instead of single Template:Tag? I have arguments against this, since this increase work for DE: RU: translators. Right now you have to make useless work after you copy&paste from en:wiki to de:wiki before you start translation. Xxzme (talk) 05:59, 22 July 2014 (UTC)

No, you don’t, but you do need to add kl=ru or vl=de if the page you’re linking to exists in your language.--Andrew (talk) 12:20, 22 July 2014 (UTC)
Well yes, |kl=ru|vl=ru works fine. But I still need to specify them manually per tag. Can we modify Tag template so it will use current namespace as default value for kl and vl? I.e. for en: namespace it will use |kl=en|vl=en, for de: namespace it will mean |kl=de|vl=de by default, etc. Unless user overwrite kl and vl values manually, they should be used from current namespace. Xxzme (talk) 23:08, 5 August 2014 (UTC)
+1, I would prefer if this happened automatically. In fact, Template:DE:Tag does no longer exist (and a lot of existing uses were deleted) because such an automatic solution was adopted for a short time around 2008. However, there were apparently technical limitations back then, see #Supporting Language Namespaces. I wonder if that is still the case? --Tordanik 05:03, 6 August 2014 (UTC)
Quick update: I recreated Template:DE:Tag based on Template:Tag. --Jgpacker (talk) 18:03, 24 October 2014 (UTC)
A suggestion: use {{Langcode}} to determine the current language and #ifexist to check whether the page exists, avoiding introducing red links by keeping links to pages in English where necessary. This allows incoming links to be switched to a version of the page in the current language whenever it becomes available.--Andrew (talk) 06:47, 7 August 2014 (UTC)
That's the behaviour I would want, too. But unfortunately these #ifexist were apparently the reason why the functionality was removed in the past. We would really need to check whether the #ifexist limit still exists. --Tordanik 07:16, 7 August 2014 (UTC)
That only affects the minority of pages that have large numbers of tag links. On those pages you make sure that enough links have the language set explicitly (which would eliminate the #ifexist call, as would using the template on pages in English), usually the ones that are already available in the current language where adding a new version of the page later has no benefit.--Andrew (talk) 11:45, 7 August 2014 (UTC)
Alright, sounds like a sensible approach. So with that obstacle cleared, I think you could go ahead and modify the template. --Tordanik 13:00, 7 August 2014 (UTC)

It appears there was a problem with the implementation? I would be interested in learning what went wrong. --Tordanik 07:02, 5 September 2014 (UTC)

I thought that change was unnecessary so I reverted myself. The changes to {{TagPagename}} were intended to test the page automatically when passed an empty string as lang= (which I think {{Tag}} does by default) but something has gone wrong somewhere as the tag links in Cs:Beginners Guide 1.4.1 all still point to pages in English and I have had no time to resolve it.--Andrew (talk) 12:04, 5 September 2014 (UTC)

Whats the current state? kl,vl ist sooo cumbersome. If there is no automatic possibility, perhaps {{DE:Tag|foo}} (and other languages) should be documented?--Jojo4u (talk) 15:19, 12 July 2015 (UTC)

It now fundamentally works; to the point where references to {{Template:JA:Tag}} have been ripped out. The one remaining problem is that repeated use of #ifexist overloads Mediawiki on pages with many uses of this template and the last ones may wrongly link to English, I am trying to alleviate this by rewriting the {{Languages}} template so that tag links get the whole ration.--Andrew (talk) 17:58, 12 July 2015 (UTC)
Out of scope. We are tlaking about Template:Tag, not about Template:Languages (that has the same issue, but which is mitigated by the fact that it tests only about 50 languages, not more, and that template is used only once per page). Template:Tag is more complex to solve and this does not involve at all Template:Languages. — Verdy_p (talk) 22:26, 3 June 2016 (UTC)
The documentation of this tag still recommends kl and vl. Should this be marked as optional now or ripped out?--Jojo4u (talk) 21:39, 3 June 2016 (UTC)
The last ones do not "wrongly" link to English, because on purpose if #ifexist cannot test a page, it will return false and the English page is still used as a fallback for these Tag templates. Yes if you know that the target language exists, you can avoid #ifexist using kl/kl. — Verdy_p (talk) 22:26, 3 June 2016 (UTC)

Appearance (grey background)

Today, I've noticed that tags formatted with this template have light grey boxes around them. I may be crazy, but it seems to me that they used to look different. So is this actually something new? And if so, why has it been changed? --Tordanik 13:50, 5 May 2016 (UTC)

It's been bluish grey since its creation in 2007. May be grey was still doo dark. — Verdy_p (talk) 15:14, 5 May 2016 (UTC)

Speaking of background, Template:TagKey and Template:TagValue have different background than Template:Tag.
Example: highway=primary highway primary.--Jojo4u (talk) 15:47, 27 May 2016 (UTC)

Fixed (initially I just changed Template:Tag to use a slightly lighter background #EEF instead of #DDE, due to the above comment. This was a test and in fact nobody disagreed on this change. So now I've applied it to the two other templates.
However this background color is still not (and has never been) plain grey, but always a bit bluish; in fact it is not really necessary to have a very distinctive background, as it just obscures the text inside (which already uses a distinctive monospace font, and also is normally bluish by effect of the link displayed; with a lighter background we also more easily see the red color of links to missing pages). I've also added the missing dir="ltr" attribute in one of them (needed for correct display of tag values on pages translated in RTL languages). — Verdy_p (talk) 05:06, 29 May 2016 (UTC)

Replace <tt> and font-family:monospace with <code>

This applies to several templates, but this is the most popular, so I'm hoping it's seen here. (I will, with a heavy heart, use some of those templates here, hoping they're changed later.)

<code> is the standard HTML element used for inline code. It's conventionally displayed with monospace font, but it's more than that. It's a semantic element. It indicates what the text is, and that's useful for, say, accessibility technologies.

Templates on this wiki indicate code in one of two ways: the obsolete <tt> element or the inline CSS font-family:monospace. Both display the text with a monospace font, but don't carry the semantic value of <code>.

I know this isn't the most active wiki, and these templates are old, maybe from before HTML5 really took hold. But unless there's a good reason to keep them this way, I think it's time for an update. --Bripmccann (talk) 16:15, 12 April 2019 (UTC)

I'm in full agreement that using semantically meaningful HTML elements is desirable. I wouldn't instinctively have considered OSM tags "code", but I guess they can be considered machine-readable keywords from a certain point of view. Seeing how the HTML spec even mentions file names as an example of something that can be put into <code> elements, I guess OSM tags do qualify. So as far as I'm concerned, your suggested change is fine, although I can't comment on if there historically was some particular reason to go with the current solution. --Tordanik 18:41, 16 April 2019 (UTC)

Can we clarify template for what?

Could it be made explicit that this is a template for the syntax of tags? Oh, but maybe it's actually about a template for wiki markup? Or people familiar with Wikipedia may think it's a page template. After a few minutes puzzling, I'm still not sure which of those three it is! We need to make the wiki as accessible as possible to people new to the map: can anyone add any clarification? eteb3 (talk) 09:29, 19 October 2019 (UTC)

This is the standard template for typing tags in this wiki. It produces a common formatting and links to the "Key:..." and "Tag:...=..." pages. Additionally, it supports namespaces and linking to the correct translation. I can not help you with Wikipedia's categories, but I started sorting out template categorisation with Category:Templates by function. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 13:46, 19 October 2019 (UTC)
Thanks. I think even more basically I need to know what a 'template' is. I think I'm inferring that a template tells you what to put in the 'Edit' box if you want a page to do X Y or Z. Is that right? eteb3 (talk) 15:05, 19 October 2019 (UTC)
A template is a piece of wiki markup you can insert by "transcluding" (meaning "adding") the template to a page. Doing so will help the editors to create a common appearance on many wiki pages. Additionally, one can change the template after transcluding it and thereby changing all pages which transclude it. The MediaWiki manual might help you: mw:Help:Templates. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 09:30, 20 October 2019 (UTC)
Thanks, i've put more or less your definition into the Glossary eteb3 (talk) 17:01, 20 October 2019 (UTC)

Automatically split values by semicolon

Do any of the tag value pages have semicolons in their names? If not, this template should automatically split the second parameter (the value parameter) on each semicolon instead of requiring the |; = and |;; = parameters, which are a bit unwieldy. It would be an opportunity to switch this template over to a Lua module, which could offer better performance and allow us to automatically split values on / as well. – Minh Nguyễn 💬 06:06, 27 November 2019 (UTC)

Well... Please name a use case for multiple values separated by a slash. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 07:06, 28 November 2019 (UTC)

@Tigerfell: That's actually quite common on this wiki, where a page wants to say something about multiple values on a given tag. Semicolons imply a simultaneous combination of values. For example:

Currently we have to use the unlinked third parameter, but it would be nice to automatically link the tags within it.

 – Minh Nguyễn 💬 18:10, 28 November 2019 (UTC)

The above syntax might be confusing for newer users. How do you want to make sure that the editors intended to merge different values instead of using an obscure value and clarify that the syntax above is not the one to note on the element? I think of tagging like highway=primary/secondary. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 09:12, 30 November 2019 (UTC)
highway=primary/secondary is exactly what I had in mind, as opposed to the /=foo|//=bar syntax we would've had to use without Lua modules. I think it would only make sense to autolink slash-delimited values in parameter 2, not the currently unlinked parameter 3. Freeform keys like name=* can contain slashes in values, but that's much less likely with the structured keys that would use parameter 2. People tend to unknowingly or accidentally use parameter 2 for value lists, resulting in redlinks anyways. – Minh Nguyễn 💬 18:04, 2 December 2019 (UTC)
No, you misunderstood me. I wrote that documenting highway=primary/secondary as a shortcut for writing "use either highway=primary or highway=secondary" might be confusing for new mappers, because they could mistake this as a valid tag for "not sure if this is primary or secondary". I can also think of a user confusing the mapping of the road infrastructure with the routes running along (some countries have an A/B/... system, there A routes are something like autobahns, B routes have meridians and straight roads and so on. So you can infer an infrastructure standard form the reference code of the route. In this context, you can find road sections with multiple numbers A1;B3009;C39090290.). --Tigerfell This user is member of the wiki team of OSM (Let's talk) 06:53, 6 December 2019 (UTC)
I see. I would be in favor of marking up alternatives less ambiguously in the rendered output. For example, we could have it output something like “primary, secondary, or tertiary” automatically (localized into the current language's list format, of course). But this output format doesn't have to be related to the input format. People are apparently used to using slashes in the value parameter in order to express a series of alternatives, so this would be merely a way to be lenient in what the template accepts. – Minh Nguyễn 💬 01:51, 7 December 2019 (UTC)
I do not want to stop you. I guess one could infer that slashes mark some sort of alternative, even without explicitly knowing the meaning in the case of tag notation. @Eteb3: Do you have an opinion about this matter. I remember talking with you about the "no knowledge rule". --Tigerfell This user is member of the wiki team of OSM (Let's talk) 12:20, 15 December 2019 (UTC)

Adding an additional parameter "desc" for showing the tag description string

See title, i see an use case when tags are listed at article "See also" sub sections.


Description Example wikitext Result
A specific key/value pair {{Tag|highway|residential}} highway=residential

Proposed new

Description Example wikitext Result
A specific key/value pair + description string {{Tag|highway|residential|desc}} highway=residential - Road in a residential area

The description string should be used from the tag article page e.g. highway=residential and there from the ValueDescription parameter "|description=Road in a residential area". Would that be useful? If so, any help for this implementation would be appreciated.--MalgiK (talk) 20:33, 4 February 2021 (UTC)

Well, I think this template is pretty complicated already, but I do not want to hinder you. I would imagine that you would need to transclude the tag or key description page and remove everything except for the description. I guess that works easier with data items, because there are templates like Template:O already. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 13:33, 7 February 2021 (UTC)
@MalgiK: Could you describe the advantage of having a built-in parameter for the description versus expecting the description to come after the template? Tigerfell's idea of automatically fetching the description from a data item is intriguing, but performance would be a concern; besides, it seems that the gloss following the template often contains not a straightforward description but rather something to distinguish one tag from another. Another issue is that the third unnamed parameter is already used for the unlinked value. In any case, I'd recommend using Template:Tag/sandbox and Module:Tag as the basis for further improvements. – Minh Nguyễn 💬 23:28, 19 September 2021 (UTC)

Database error with HTML character entity reference to emoji

Starting with Special:Diff/1942679, Proposed features/name:Zsye has failed to load due to a database query error:

[ed41d04dcf250dd265e0e5e8] 2021-12-01 01:50:41: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"

The culprit is this invocation of {{Tag}}, which triggers the error on its own in Special:ExpandTemplates:


I'm not sure where exactly the error lies, because {{TagPagename}} seems to have no problem with this 🇺🇸 sequence (incorrect as it is). It's almost certainly related to this wiki's lack of support for non-BMP characters, but the wiki is normally OK with HTML character entity references.

 – Minh Nguyễn 💬 01:55, 1 December 2021 (UTC)

The issue appears to be generating links; changing | to || in the wikitext fixes it. --Andrew (talk) 20:57, 1 December 2021 (UTC)