Template talk:Tag

From OpenStreetMap Wiki
Jump to: navigation, 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)

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 {{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)