Template talk:Tag

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)

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
{{tag\|width\|\|#}}	`width=#`	# interpreted as ordered list
{{tag\|width\|\|*}}	`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
{{tag\|width\|\|<nowiki>#</nowiki>}}	`width=#`

--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
{{tag\|psv:lanes\|\|<nowiki>yes\|no\|no</nowiki>}}	`psv:lanes=yes\|no\|no`

--User:Aceman444 19:28, 30 Dec 2013 (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)

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)

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

(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:

Tag:amenity=pharmacy: "wheelchair=yes/no/limited"
Tag:man_made=flagpole: "flag:type=signal/national/governmental/..."
Proposed features/change: "change=yes/no/not_right/not_left"

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

(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

(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

(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.

Current

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

(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:

{{Tag|name:Zsye|'''&#127482;&#127480;'''}}

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)

Introducing a sep parameter

The current syntax for multiple values is quite cumbersome and only supports up to three values e.g.

{{Tag|some_tag|foo|;=bar|;;=baz}} → some_tag=foo;bar;baz
{{Tag|some_tag|foo|;=bar|;;=baz|;;;=buz}} → some_tag=foo;bar;baz (buz is not shown because only two values are supported)

And as noted in #Automatically split values by semicolon some auto-linking support for slash separated values would be handy for proposals.

So I think we should introduce a sep (separator) parameter so that you could do:

{{Tag|some_tag|foo;bar;baz|sep=;}} → some_tag=foo;bar;baz
{{Tag|some_tag|foo/bar/baz|sep=/}} → some_tag=foo/bar/baz
{{Tag|some_tag|foo{{!}bar{{!}}baz|sep={{!}}}} → some_tag=foo|bar|baz

(This would require some Lua scripting but I think it should be easy to implement.) What do you think about this?

--Push-f (talk) 11:40, 21 July 2022 (UTC)

Lua rewrite

I've rewritten this template to be based on Module:Tag instead of wikitext. In general, there should be no difference to the input or output, but the new template supports an arbitrary number of key parts and values, not just three.

Some aspects of performance should also improve under the new implementation. The difference should be significant on pages that transclude this template many times. The following comparisons are somewhat pessimistic, because these pages transclude many templates such as {{TagValue}} and {{Valuelink}} that have some of the same performance problems as the current {{Tag}} implementation:

Template:Map Features:amenity – 19% faster, 25% smaller

How to map a – 22% faster, 24% smaller

MUTCD/R – 34% faster, 23% smaller

United States roads tagging/Routes – 21% faster, 20% smaller

Homonymous keys – 31% faster, 23% smaller

The Lua module is passing a battery of tests, but more test cases are always welcome. If no showstopping issues are identified, I'd like to deploy this rewrite soon, then proceed to similar templates like {{TagValue}}, so that the operations team can identify other non-template-related bottlenecks.

– Minh Nguyễn ^💬 23:11, 11 April 2024 (UTC)

See https://github.com/openstreetmap/operations/issues/1046 for anyone confused by "operations team" phrase. Mateusz Konieczny (talk) 01:29, 12 April 2024 (UTC)

Performance improvements are nice in general! Thanks for them! What about code readability/maintainability? Extra require dependencies? How it changed? Though given dramatic situation we likely would need to use it anyway Mateusz Konieczny (talk) 01:29, 12 April 2024 (UTC)

@Mateusz Konieczny: I may be biased, but I find Module:Tag to be much more comprehensible and maintainable than the current Template:Tag. For example, I think it would've been challenging to implement |::: = or |;;; = in the current wikitext implementation. In addition to the performance improvements, I also fixed some bugs along the way. For example, wikimedia_commons=File:Example.png now links to Wikimedia Commons instead of commons=File:Example.png. Aside from bug fixes and support for an arbitrary number of colons and semicolons, I tried to keep the behavior exactly the same.

Module:Tag does depend on Module:Languages, but most pages on the wiki already transclude {{Languages}}, which also depends on that module, so there's negligible overhead. Unlike a template, a data module such as Module:Languages/config gets loaded only once no matter how many times the page requires it.

– Minh Nguyễn ^💬 04:43, 12 April 2024 (UTC)

I've proposed a Lua port of {{TagValue}} as well. – Minh Nguyễn ^💬 16:51, 14 April 2024 (UTC)

And finally a port of {{TagKey}}, completing the set. – Minh Nguyễn ^💬 18:40, 25 April 2024 (UTC)

Template talk:Tag

Contents

Performance problems

lists of values

Whitespace handling

Third param wiki interpretation

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

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

Automatically split values by semicolon

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

Current

Proposed new

Database error with HTML character entity reference to emoji

Introducing a sep parameter

Lua rewrite

Navigation menu

Template talk:Tag

Performance problems

lists of values

Whitespace handling

Third param wiki interpretation

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

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

Automatically split values by semicolon

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

Current

Proposed new

Database error with HTML character entity reference to emoji

Introducing a sep parameter

Lua rewrite

Navigation menu

Search