Template talk:Description

From OpenStreetMap Wiki
Jump to navigation Jump to search

Website and URL pattern

It seems we need to continue the discussion from Template_talk:KeyDescription#Website and URL pattern because the fields in question have been carried over to the unified template. Given that a majority had stated their opposition to these highly specialized fields, and Andy did not respond to the objections for two weeks, I think these fields should be removed from this template again unless convincing new arguments are brought forward. --Tordanik 20:11, 18 April 2014 (UTC)

We should be having any discussions of these useful parameters in a more prominent place than one user's transitive sub-page's talk page; I'll respond at Template_talk:KeyDescription. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:16, 18 April 2014 (UTC)

Formatting of parameters

Hi Moresby, I think you should stop trying to format the parameters in templates by including spaces. I use a different font or editor than you do apparently and therefore it actually looks worse after you add those spaces to have equal signs aligned. I believe that this will be true for others as well. Thanks.Chrabros (talk) 05:33, 23 April 2014 (UTC)


Templates without image parameter

Now that the dust of the big changes has settled, I'd like to bring up the topic of how to handle templates with no image being set. The current behaviour (which was introduced along with the template restructuring) is to show a huge version of the "key" or "key=value" icon. I would prefer if we would just use no image at all in those cases (e.g. abstract things like Key:type). --Tordanik 08:45, 27 June 2014 (UTC)

The only image I could think of for type is the relation icon. While there are certainly pages without images that could have them, an abstract image or the old way of nagging about it with “No image yet” seems pointless. --Andrew (talk) 08:17, 28 June 2014 (UTC)

Wikidata

There is a discussion on whether/how to keep the recently added wikidata parameter at Template talk:ValueDescription#Wikidata.--Andrew (talk) 12:03, 2 September 2014 (UTC)--Andrew (talk) 12:03, 2 September 2014 (UTC)


Resolved: Appears to be resolved with Proposed features/remove link to Wikidata from infoboxes Mateusz Konieczny (talk) 22:38, 1 May 2022 (UTC)

Wikidata link

Having a magic number that links to a cryptic page can frighten new users and wastes space for established ones who will tune it out. Wikipedia doesn’t link like this even when it generates content from Wikidata. Even if having the reference makes sense for machine reading pages it shouldn’t be visible.--Andrew (talk) 09:56, 30 December 2014 (UTC)

Please do not remove the Wikidata link. The hookum that this "can frighten new users" is without foundation, and we are not going to run out of space on our wiki pages. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:44, 30 December 2014 (UTC)
I agree that it can be slightly problematic. Most users probably don't know what Wikidata is. Wikipedia links are more usable/friendly and often available in the wiki page. As Wynndale pointed out, we can leave the parameter without making it visible. --Jgpacker (talk) 14:27, 30 December 2014 (UTC)
You may agree, but where is the evidence? Hiding values is harmful; it leads to people not spotting errors. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:05, 30 December 2014 (UTC)
"Hiding values is harmful; it leads to people not spotting errors." - (a) I support removal also of such unused parameter from article text. (b) infobox is not a place to put anything at least a bit related and every single possible link, as Wikidata link has nearly no use I support its elimination Mateusz Konieczny (talk) 18:58, 9 May 2020 (UTC)
"Wikidata link has nearly no use" is false. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:10, 9 May 2020 (UTC)
How it is supposed to be used? Primary claimed use is bizarre case of someone frequently using Wikidata to query data about matching object, but not using data items and doing it manually based on infobox links. Maybe it is something rarely done by people, but it is not something that is highly important to describe OSM tags. In addition links are very often misleading because Wikidata items and OSM tags very rarely match 1:1 Mateusz Konieczny (talk) 00:05, 10 May 2020 (UTC)
Wynndale, so what is your proposed action? What does Wikipedia use to link to Wikidata?--Jojo4u (talk) 13:08, 7 February 2015 (UTC)
Wikipedia uses Wikidata by searching in it an item that matches the current page name (in the "wikipedia" properties). When an entry is found, it will list the other "wikipedia" links found in the matching Wikidata entry (those entries will be added to those for which there are explicit interwikis to specific wikipedias (but those are now deprecated and no longer necessary: if they are present, they override the interwikis found in Wikidata for the same language, and the link found in Wikidata will not be displayed; but Wikipedia will still incldue a link at the bottom of the list to show the existing Wikidata page that has been found).
However this OSM wiki still does not know how to query Wikidata to retrieve a list of Wikipedias (in fact this wiki does not perform any query to Wikidata, it does not even have an interwiki for it, so we link Wikidata via wikipedia, or use absolute URLs). Effectively this wiki does not have the MediaWiki extension for the Wikidata client. — Verdy_p (talk) 17:11, 26 May 2015 (UTC)
"Wikipedia uses Wikidata" this is not relevant at all. How adding wikidata parameter to Description template helps anything in OSM wiki? Mateusz Konieczny (talk) 12:34, 4 November 2017 (UTC)
You truncate a sentence that explains what Wikipedia does to retrieve the list of other wikipedias on the same topic: yes it uses Wikidata.
So the question is: do we need Wikidata or Wikipedia links? If we need Wikipedia, it is do avoid having to document many things, but a single Wikipedia is not relevant for all, and other languistic editions are relevant as well, but we cvannot link hundreds of Wikipedias! So we can link to Wikidata and this gives the full list of Wikipedia, plus many other classifation data and useful data from Wikidata only without having to read the full rendered Wikipedia articles. With Wikidata we also get links to Commons (for galeries, categories, or documents such as book scans, or Wikisource, or definitions in Wiktionary, and really many sources). Wikidata has a solid categorization system which includes many qualifiers, it gets always better, and often will be a better reference now than a single Wikipedia article (where multiple topics will be frequently merged even iof they are clearly distinguished in Wikidata).
Not all cities in the world have a Wikipedia article in any language (or sometimes only in an unrelated language), but all those that have a pedia article will also have an entry in Wikidata (if not, it is instantly created). Wikidata is more inclusive (against forgotten missing items) and more precise in all cases (ans also more accessible).
But we don't have Key or Tag wiki pages for individual cities, we have a page place=city which is used in a way that is much different than the definition of "city" in US English or British English. Even more different are the place=suburb vs https://www.wikidata.org/wiki/Q188509. --Jeisenbe (talk) 23:55, 9 May 2020 (UTC)
Wikidata is finally useful beause its classification of concepts is more precise, and more checked (before that, it was partilly checked on Commons, but never really checked on English Wikippedia, and this caused problems when articles in Wikipedia were renamed, merged, and split in separate articles (the main topic was actually changed, this should never happen in Wikidata that will preserve the explicit distinctions). — Verdy_p (talk) 15:54, 4 November 2017 (UTC)
"Not all cities in the world have a Wikipedia article in any language" how it is relevant to linking to wikidata from description of tags? Mateusz Konieczny (talk) 16:15, 4 November 2017 (UTC)
"Wikidata is finally useful beause its classification of concepts is more precise, and more checked" - can you give any example of using this classification in context of OSM tags? Mateusz Konieczny (talk) 16:15, 4 November 2017 (UTC)
"With Wikidata we also get links to Commons" - images, if useful, may be already directly placed or linked from articles Mateusz Konieczny (talk) 16:15, 4 November 2017 (UTC)
"Wikidata is finally useful" - putting useless links to inflate supposed Wikidata use is not a good idea. It is an OSM Wiki, not promote Wikidata WIki Mateusz Konieczny (talk) 00:12, 10 May 2020 (UTC)


Resolved: Appears to be resolved with Proposed features/remove link to Wikidata from infoboxes Mateusz Konieczny (talk) 22:38, 1 May 2022 (UTC)

One discussion place

Currently discussion about Template:Description is spread over this page and Template talk:KeyDescription, Template talk:ValueDescription. This triples the time to check and lowers chance of successful discussion to one third. I propose to put an ambox on the top and bottom of Template talk:KeyDescription, Template talk:ValueDescription, Template talk:RelationDescription that topics which affect alle those templates should be done over here.--Jojo4u (talk) 12:07, 22 May 2016 (UTC)

Good idea. My plan is to mark old resolved discussion as resolved, archive them, move still active discussions here, merge archives, redirect archived, redirect talk pages Mateusz Konieczny (talk) 22:26, 9 January 2021 (UTC)
I would also include sharing talk pages of /doc subpages Mateusz Konieczny (talk) 08:04, 22 January 2021 (UTC)
I agree, let's do it. --Jeisenbe (talk) 17:46, 24 January 2021 (UTC)
Resolved: done Mateusz Konieczny (talk) 22:45, 1 May 2022 (UTC)

Support of value only

The values *=construction and *=proposed are used for many keys with the same meaning. Potentially also *=sidewalk (for footway, path, cycleway). Using Template:ValueDescription with key=* and value=construction gives links to Key:* and Tag:*=scheduled which looks not good.

  1. What would be the best way of using the current templates for *=construction?
  2. Would another template (e.g. ValueOnlyDescription) be useful?
  3. What about a new namespace https://wiki.openstreetmap.org/wiki/Value: ?

--Jojo4u (talk) 13:52, 22 May 2016 (UTC)

Also access=designated and all other access=*.--Jojo4u (talk) 13:54, 17 April 2017 (UTC)


Lego strings

I propose changing dropping the {{localised-colon}} from {{DescriptionLang|Status|{{{lang|}}}}}{{localised-colon|lang={{{lang|}}}}} and moving the colons into the status strings. This gives a slightly more optimised template and the opportunity to handle colons differently in some languages. --Andrew (talk) 07:33, 25 June 2019 (UTC)

This means that {{DescriptionLang|Status}} returns Status: followed by a space in English and similar equivalents in other languages. --Andrew (talk) 15:08, 30 June 2019 (UTC)
That sounds reasonable. Alternatively, we could replace {{Localised-colon}} with MediaWiki:Colon-separator or MediaWiki:Metadata-langitem. {{int:colon-separator}} would be dependent on the current interface language; if we really need to maintain compatibility with |lang =, then we could use mw.message in a module to get the message in the correct language: mw.message.new("localised-colon"):inLanguage(frame.args.lang). – Minh Nguyễn 💬 22:35, 30 June 2019 (UTC)


Recent addition of rendering samples

[User:MalgiK] - What was the reason for these changes: https://wiki.openstreetmap.org/w/index.php?title=Template%3ADescription&type=revision&diff=1930091&oldid=1872970 ? Is it really necessary to have separate rendering samples for nodes, lines and areas? --Jeisenbe (talk) 17:16, 11 December 2019 (UTC)

The reason is to show different pictures of carto-rendering for objects which have different rendering, depending if these are tagged as a node element or as an area element. You could see cases in this list AreasTab, there are tags which having a symbol as node and symbol+area as area rendering. My initial attempt to tell wiki article readers this information via VD-Box was like these examples (putting two picture under osmcarto-rendering):
=> https://wiki.openstreetmap.org/w/index.php?title=Tag:railway%3Dstation&oldid=1929387
=> https://wiki.openstreetmap.org/w/index.php?title=Tag:leisure%3Ddog_park&oldid=1898576
both visualizations are not really looking nice, also by showing square-bracket open [[ & square-bracket close ]] characters
The next attempt was to use the mentioned additional VD-box-parameters, so currently it looks like this:
=> https://wiki.openstreetmap.org/w/index.php?title=DE:Tag:leisure%3Ddog_park&direction=next&oldid=1930794
This alternative is for user [User:Geozeisig] and me more acceptable, because at least without showing [[ and ]] characters
There are 2 other talks which belongs a bit to this topic, see here (sorry is in German):
=> https://wiki.openstreetmap.org/wiki/User_talk:Tigerfell#Syntax_f.C3.BCr_mehrere_Symbole_in_einer_Zeile
=> https://wiki.openstreetmap.org/wiki/DE_talk:Tag:amenity%3Dpolice#osmcarto-rendering
If you have better idea/ideas i'm happy to hear and see it :-)--MalgiK (talk) 12:10, 12 December 2019 (UTC)
+1, infobox is for summary and anyway in OSM Carto it is rare that showing all three variants to add any useful info above showing one representative case Mateusz Konieczny (talk) 21:59, 11 December 2019 (UTC)
One factor which (I believe) hasn't been considered so far is the lack of Taginfo compatibility with the new parameters. Making this field available to Taginfo is the main reason for having it part of the infobox at all. In particular, the goal was to be able to include rendering examples in Taginfo/Taglists, as Map features was using this kind of column and we wouldn't have been able to replace such tables otherwise. If machine-readability isn't a factor, images could just be placed in a gallery in a "Rendering" section on the page, and this would in fact be my suggestion for situations where a single image isn't sufficient. Not only would this easily allow multiple images for Carto plus any explanatory text that's necessary, but it would also allow examples from other renderers and applications to be featured with equal prominence. --Tordanik 16:38, 21 December 2019 (UTC)
Right, i didn't know, that the parameter osmcarto-rendering came via this change in Sept 2016 into the info-box, and that only because of the goal to fill an additional column (title: "Map rendering") for the Taginfo/Taglists tables. [btw1/2] But it seems there are many other parameters implemented at the info-box which all also not used for Taglist computing (e.g. group, requires, implies, combination, seeAlso, status, statuslink, website, and so on). So why not have 3 more (osmcarto-rendering-node, osmcarto-rendering-way, osmcarto-rendering-area) which are not used for Taglists?
For me i like the goal & idea to see and find the rendered icon/colour for each tag on his tag wiki article page on the same defined position. The position at into-box seems perfect, so in other words, in my opinion the rendering data at info-box is fine, even if this wouldn't be used for Taglists.
[btw1] Is there any option to preview wiki-articles changes on any wiki-articles which using these Taglists without this error "LOADING TAG LIST... (If you do not see this tag list, you need to enable Javascript)"?
[btw2] How/where can we change the column title text from "Map rendering" to maybe "carto-Rendering" and set an additional link to Standard tile layer? --MalgiK (talk) 08:50, 4 January 2020 (UTC)
Can we please revert the changes to the template? It appears that this change is not necessary and will cause problems with Taginfo. --Jeisenbe (talk)`
How would you show via info-box that e.g. for leisure=dog_park the Dog park.svg is used for node node objects and Leisure dog park 100.png is used for area area objects. What is the problem with Taginfo in detail? --MalgiK (talk) 19:30, 18 February 2020 (UTC)
The leisure=dog_park rendering needs to be fixed, we have an open issue about that. It doesn't make sense for us to use a different icon for the area and a node. But this can easily be shown by adding an image in the main text of the wiki page. It doesn't need to be in the ValueDescription or KeyDescription box, because these are meant to be machine-readable tags for use by Taginfo and editor apps, where one sample is sufficient. --Jeisenbe (talk) 12:12, 19 February 2020 (UTC)
It's not only a question for tag leisure=dog_park, e.g. also for tag highway=platform (the Rendering-highway railway platform line.png is used for way way objects and Rendering-highway railway platform area.png is used for area area objects). Actually i'm not so happy about to illustrate the rendering for some tags in the info-box and for some other tags in the main article text. I still not complete understand, why this version to show different pictures in the info-box, could/should not be possible. Btw how is the current rendering for hedges? I remember there was a render change, but i did not check in detail, are there also different renderings for lines and areas? --MalgiK (talk) 15:13, 20 February 2020 (UTC)
"Openstreetmap Carto" is just one map style. While it is influencial, a single rendering sample for each feature is more than enough. If we are going to include more than one rendering sample, it would be much better to show a sample the Humanitarian (HDM) layer or one of the other map layers on openstreetmap.org rather than showing minor differences in the rendering of areas vs ways vs nodes in one style. (And yes, hedge areas and ways now have the same rendering, so that is one less issue). --Jeisenbe (talk) 05:32, 21 February 2020 (UTC)


Remove wikidata from this template

I plan to remove the wikidata lines from this template, per discussion here (above: https://wiki.openstreetmap.org/wiki/Template_talk:Description#Wikidata and https://wiki.openstreetmap.org/wiki/Template_talk:Description#Wikidata_link) and on the related ValueDescription template (see https://wiki.openstreetmap.org/wiki/Template_talk:ValueDescription#Wikidata) and on the Talk mailing list (Starting at https://lists.openstreetmap.org/pipermail/talk/2020-May/084637.html). --Jeisenbe (talk) 21:43, 4 May 2020 (UTC)

This has been done now, seeing there were no objections. --Jeisenbe (talk) 21:34, 8 May 2020 (UTC)
If you really think there were no objections in the linked discussions you need to re-read them. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:14, 9 May 2020 (UTC)
Are you sure that you posted what you wanted to post? "seeing there were no objections." is clearly untrue. See linked https://wiki.openstreetmap.org/wiki/Template_talk:Description#Wikidata_link with "Hiding values is harmful; it leads to people not spotting errors." Mateusz Konieczny (talk) 18:59, 9 May 2020 (UTC)
To be clear, I fully support removal of this parameter. It still remains unclear why we would want such prominent links to Wikidata on OSM Wiki. Comment of edit was OK and without mistake like here in the discussion. Mateusz Konieczny (talk) 19:07, 9 May 2020 (UTC)
The reasons why have been explained to you previously. Whether you don't understand them or don't like them does not make them less real. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:15, 9 May 2020 (UTC)
"explained to you" - this is untrue. Given claims appeared to me extremely weak, I asked for clarification/conformation that was never made. Primary claimed use is bizarre case of someone frequently using Wikidata to query data about matching object, but not using data items and doing it manually based on infobox links. Maybe it is something rarely done by people, but it is not something that is highly important to describe OSM tags. Given extremely low data quality of links it appears that this is not used for anything. And putting this useless link above taginfo statistics is ridiculous. Mateusz Konieczny (talk) 23:59, 9 May 2020 (UTC)
Your claim that explanations have not been given is undermined by the fact that you have replied to those explanations Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:03, 10 May 2020 (UTC)
Explanations were weak, incomplete and unclear. To repeat myself "I asked for clarification/conformation that was never made". Some comments were made, but were insufficient to explain anything. Mateusz Konieczny (talk) 15:11, 10 May 2020 (UTC)
Those would be the explanations that you just denied were given? As I said, you not understanding them or not liking them does not make them less real. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:52, 10 May 2020 (UTC)
I meant that no one had objected during the current discussion period in 2020. The only objections were from Andy Mabbett in 2014 and 2018. --Jeisenbe (talk) 23:26, 9 May 2020 (UTC)
Well, technically Verdy_p also defended this link at https://wiki.openstreetmap.org/wiki/Template_talk:Description#Wikidata_link with justification that it should be kept because it makes "Wikidata finally useful", without explaining whatever and how it improves OSM Wiki. Mateusz Konieczny (talk) 00:17, 10 May 2020 (UTC)
Re: "Hiding values is harmful; it leads to people not spotting errors" - this appears to be the main objection? The problem is that I consider almost all of the current wikidata values on Tag and Key pages to be errors, since they usually link to the general wikidata concept which is similar to the key or value, rather than linking to a wikidata item specifically about the OpenStreetMap tag. --Jeisenbe (talk) 23:26, 9 May 2020 (UTC)
Re: "machine-readable metadata"... is available from the link at wikidata: this is usually incorrect, since most of the wikidata links are to a related, general concept like e.g. "cemeteries", rather than what landuse=cemetery means in OpenStreetMap and how it is different from an amenity=grave_yard. Occasonally the wikidata item is one that was made up specifically to link to the OpenStreetMap tag, but in that case there is no additional data available at wikidata which you can't find here or in the Data Items (wikibase). --Jeisenbe (talk) 23:26, 9 May 2020 (UTC)
You don't get to arbitrarily reset the clock. That the discussion has been open for some time does not invalidate comments made in it. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:03, 10 May 2020 (UTC)
I attempted to review discussion and my summary is as follows: there is a consensus for removal of Wikidata link from the infobox template, there is no unanimous support for that as for example Pigsonthewing and Verdy_p opposed. There is no clear use case for such link in the context of editing OSM. Such Wikidata links are confusing (identifiers are not human friendly, collision with Data item identifiers), are not important enough to be linked in infobox. Also, such links may confuse people about copyright status of Wikidata database. Wikidata database due to copyright differences us uneligible for import into OSM. It contains content systematically copied from copyrighted databases, for example English Wikipedia encourages copying location info from Goggle Maps what was (is?) then automatically copied into Wikidata (note: this may not be copyright/copyright-like violation under US law, but it is problem under UE rules). In general this wikidata link is not adding any additional information about OSM tags and is not a significant help in any OSM task. Also, presence of this link in infobox misleads people into wasting time on adding them. I plan to remove this parameter and ask Pigsonthewing to not reintroduce it. Maybe we are mistaken, but this Wikidata link is clearly unwanted, unsupported, undesirable and considered as nearly/completely useless for OSM mappers. Note that this links (with their highly dubious quality and usefulness) will remain in data items. If someone wants to do something rare, unusual, and in general not useful for OSM mapping like using Wikidata or its query service, and link between OSM tag and Wikidata item will be assumed to be true, then use https://wiki.openstreetmap.org/wiki/Property:P12 on data items. And if Pigsonthewing or someone else is convinced that discussion was mishandled, not presenting full facts or in some other way faulty - feel free to start discussion about reintroducing this parameter, and in case of support similar to one expressed its removal will be voiced then it can be added back (note that discussion should take place in standard appropriate discussion location like OSM Wiki talk pages or talk mailing list). Mateusz Konieczny (talk) 07:06, 10 May 2020 (UTC)
Your partisan reading of the discussion does not accord with reality; it is not for you to act as judge, jury and executioner. I have restored the status quo ante. You need to cease your edit warring and wait for a natural and recognisable consensus to emerge. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:59, 10 May 2020 (UTC)
You seem to confuse consensus and unanimous support. In this case we have a widespread agreement and extreme minority opposing it. It means that there is no unanimous support but we have a consensus to make this action. "it is not for you to act as judge, jury and executioner" - good idea. I will try to @Tigerfell:, maybe he will be interested in reviewing this situation. "wait for a natural and recognisable consensus to emerge". I am pretty sure that it already emerged in discussions. Mateusz Konieczny (talk) 15:16, 10 May 2020 (UTC)
"You need to cease your edit warring". We have no strictly defined limit of what becomes an edit war, but Pigsonthewing is sole recent editor on this page who crossed 3 revert rule used on English Wikipedia - "there is a bright-line rule called the three-revert rule (3RR), the violation of which often leads to a block." and on enwiki you would almost certainly receive short term block. Please avoid doing something and immediately accusing others of doing that Mateusz Konieczny (talk) 15:22, 10 May 2020 (UTC)
I am not confusing anything. HTH. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:52, 10 May 2020 (UTC)

As far as I can see, there are two main arguments one for each side:

  • Users might retrieve additional information from the linked Wikidata item, because it contains a short description and links to other web pages (Wikipedia, WM Commons, etc.).
  • Users might be confused by the additional information, because it contradicts with the information provided by the wiki page.

I do not see that there are objective reasons to choose one over the other. That is why I would suggest that you initiate a voting similar to the proposal voting (because this procedure is already established) asking the voters whether the Wikidata data item information should be removed. You might want to include Data items in the proposal because they essentially link to Wiki data, too. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 11:08, 11 May 2020 (UTC)

proposal voting to remove seems unusually high barrier given that it was added without any real discussion (adding it was OK, I assume that whoever added it wanted to improve OSM Wiki) Mateusz Konieczny (talk) 11:36, 11 May 2020 (UTC)
Still, sooner or later I will make such proposal. Pigsonthewing, if you think that there is better defense of Wikidata linking than summary by Tigerfell feel free to state it and I will include it in this proposal. Mateusz Konieczny (talk) 11:39, 11 May 2020 (UTC)
I believe the proposal should ask the question "Should the Wikidata link be added to the Infobox?" - because the original addition of this feature was not approved by the community in this way. --Jeisenbe (talk) 00:47, 12 May 2020 (UTC)
Still, support for this link is so low that I expect that any kind of voting will result in its removal (making it quite redundant, but it may be easier than this ongoing discussion) Mateusz Konieczny (talk) 20:00, 12 May 2020 (UTC)
Proposed features/remove link to Wikidata from infoboxes is now getting created Mateusz Konieczny (talk) 18:55, 7 January 2021 (UTC)

The removal proposed by Jeisenbe and Mateusz Konieczny would be implemented by copying this change from the sandbox to {{Description}}. I'm mentioning this here because I'm about to update that sandbox to the newest template code and overwrite it with an alternative proposal for consideration, but I don't want to leave the impression that I'm trying to undermine the existing proposal backhandedly. – Minh Nguyễn 💬 08:08, 20 January 2021 (UTC)

I Symbol support vote.svg Support removing Wikidata from this template, in particular when no parameter is given. "Search Wikidata" doesn't work anyway. maro21 15:36, 3 May 2021 (UTC)
Resolved: Appears to be resolved with Proposed features/remove link to Wikidata from infoboxes Mateusz Konieczny (talk) 22:38, 1 May 2022 (UTC)

Language Question about v * d * e

Just exploring the topic of template, and exactly how they work and their purpose, so forgive me if this has already been answered. When I hover over the "v" at the top of the template page I see: "View this template." and when I hover over "e" I see: "Edit this template.", but when I hover over "d" I see: "Discuter de ce modele." I assume this means something with going to the talk page, but I think would be nice if my set language (english) would translate this item. How can I address this issue? And/or can this even be fixed? Thanks! --IanVG (talk) 16:50, 24 December 2020 (UTC)

Could you tell me the page where you saw it? The text should be in English. I checked on some pages, even on those with FR: prefix and everywhere I can see it in English. I thought this text comes from Template:Navbar, but it doesn't. It is somewhere deeper, maybe in a Wiki extension. maro21 01:59, 25 December 2020 (UTC)
Hmmm, interesting. I looked into it a little bit as well, and I came to the conclusion that it had to be from the Template:Navbar, but perhaps not. For example on the Key:barrier page, I am still getting the french translation for "d".--IanVG (talk) 00:19, 26 December 2020 (UTC)
You're right - when I switched interface language to English, I can see it in French too. The title when you hover a cursor comes from this template and it depends on the user's interface language.
This template isn't written well - the hover texts are not language specific, but depend on a word for "discussion" in the language. Here: discussion is both in English and in French. So both of them will see the French text.
discussion = Discuter de ce modèle.
So every language with the word "discussion" for discussion/talk will have this French text. maro21 16:43, 26 December 2020 (UTC)
I fixed it. But now French users will see an English text there. Sorry, no better solution right now. If we want to have separate texts for every language, the template has to be rewritten to use language codes, not words. We could use the template from Wikipedia, but the comment in the Navbar template suggests that's impossible right now Caveat: ideally we should switch on ⧼Lang⧽ but it still does not work on this wiki, so detect the UI language by using another working resource name. maro21 16:52, 26 December 2020 (UTC)


Proposal to merge part of documentation

Can we merge for example https://wiki.openstreetmap.org/wiki/Template:KeyDescription/doc#Additional_information https://wiki.openstreetmap.org/wiki/Template:ValueDescription/doc#Additional_information and inline that? Description is the same in both, currently you need to remember to make the same edit in both... Mateusz Konieczny (talk) 14:29, 10 January 2021 (UTC)

Replacing each field's description with See [[Template:ValueDescription/doc#Additional_information]] would keep it trivial to fork that field's doc in the future, should the need arise, by replacing the wikilink with a copy-paste. --Opk12 (talk) 13:48, 26 March 2021 (UTC)

Merge discussions

There is a proposal to have one talk page for Template:Description, Template:KeyDescription and Template:ValueDescription and their doc subpages. See Template_talk:Description#One_discussion_place Mateusz Konieczny (talk) 08:04, 22 January 2021 (UTC)

Misleading tooltip (alt text) for relation

https://wiki.openstreetmap.org/wiki/Tag:amenity=police has tooltip over "no relation" symbol that applies to non-multipolygon relations "should not be used on relations".

I propose to change it to "should not be used on relations (applies to relation except multipolygons, counted as areas)"

Similarly "should not be used on ways" should be changed to "should not be used on ways (excludes closed filled ways, counted as areas)"

"may be used on areas" should be "may be used on areas (multipolygons and closed filled ways)"

Obviously both negated and not negated versions should be changed.

Where it is defined?

triggered by https://github.com/streetcomplete/StreetComplete/pull/2675#discussion_r602060620 Mateusz Konieczny (talk) 12:30, 26 March 2021 (UTC)

Template:KeyDescription defines onWay and onRelation like in your post since May 2015. Template:ValueDescription does since 2014. The clarification was brought over to Template:Description for onRelation only, in 2015.
But the fields appear intended to have the same meaning anyway, so I'd assume that onWay should also be clarified in the template doc to mean non-closed, and then the tooltip text implementation is just not honoring the docs.
This duplication across three pages makes it error-prone to update them all and would be solved by #Proposal_to_merge_part_of_documentation. --Opk12 (talk) 13:47, 26 March 2021 (UTC)
Note that you can have closed not filled ways (for example highway=cycleway or leisure=track or man_made=embankment or natural=cliff forming loop) Mateusz Konieczny (talk) 20:55, 26 March 2021 (UTC)
Ah, I did not know that, sorry. --Opk12 (talk) 08:26, 27 August 2021 (UTC)

Category:Feature pages with missing images

Resolved

I would like to change the category name added by this template from Category:Feature pages with missing images to Category:Pages with missing images. Is there anyone against it?

Although this category contains "feature pages with missing images" like for example Alm, it also contains key and tag pages (mainly) which are not features. See also Category talk:Feature pages with missing images. --maro21 22:14, 22 July 2021 (UTC)

Maybe "Tagging pages with missing images"? Mateusz Konieczny (talk) 03:08, 23 July 2021 (UTC)
@Maro21: are you planning to do this? Mateusz Konieczny (talk) 07:28, 9 March 2022 (UTC)
I was planning to do this, but something stopped me. I don't remember now what was it, I need to check it again. maro21 22:12, 9 March 2022 (UTC)
So I created Category:Tag and key pages with missing images. I left Category:Feature pages with missing images which contains non-tag and non-key pages. maro21 14:02, 20 March 2022 (UTC)

Fetch osmcarto-rendering from Data Items

Would it be possible to add fetching OSM Carto rendering example from Data Items like we have it for other parameters? maro21 01:29, 10 December 2021 (UTC)

@Maro21: Done in Special:Diff/2222696/2228563 and Special:Diff/2228565. – Minh Nguyễn 💬 07:17, 11 December 2021 (UTC)

Thank you!!! :) This will make it easier for me to work on adding the missing renderings.
As far as I can see, it was once coded but just didn't work?

En example how it works: Cs:Tag:railway=halt - icons are smaller than the stadard size we use [28px], and areas are bigger Cs:Tag:landuse=railway.

But that's not a big problem - the icons will be the actual size, they won't be enlarged, and the areas will just be a little bigger. It just won't be identical in different language versions.

I thought of setting the default image size, but after all, the Wiki can't know if it's an icon [28px] or an area [100px]... maro21 16:42, 11 December 2021 (UTC)

@Maro21: I don't know the backstory, but there was code for rendering image (DEPRECATED) (P38), which was deprecated in favor of OSM Carto image (P39) just a few days later. It was hooked up to a |rendered = parameter that doesn't exist, so maybe there was a short-lived plan to generalize the |osmcarto-rendering = parameter to cover other renderers as well.

The module currently uses the image at its nominal natural size. It's possible to override the size in wikitext, but ideally there would be a qualifier property to indicate the preferred size, and maybe the element type being rendered. Property creation is currently limited to the data administrators group. I guess the process would be to propose the property at Talk:Data items.

 – Minh Nguyễn 💬 07:29, 12 December 2021 (UTC)

Why underscores are bad?

https://wiki.openstreetmap.org/w/index.php?title=Template:KeyDescription/doc&curid=48110&diff=2280230&oldid=2278620

@Maro21: "use spaces instead of underscores" - why? OSM Wiki works fine with either Mateusz Konieczny (talk) 07:26, 9 March 2022 (UTC)

This Category talk:Mismatched image is the main reason - the script comparing images doesn't work properly. maro21 22:06, 9 March 2022 (UTC)
Deficiencies of data items should not be a consideration when editing OSM Wiki, underscores are fine. The script should be fixed rather than making such demands from people editing OSM Wiki Mateusz Konieczny (talk) 05:53, 10 March 2022 (UTC)
It's not a demand, it's just a recommendation, for code readability.
This applies not only to underscores but also to other special characters.
See, for example I can link to a thread in this page in 2 ways:
Template_talk:Description#Language_Question_about_v_.2A_d_.2A_e or
Template talk:Description#Language Question about v * d * e - the links go to the same place, but the second one is more readable. maro21 14:32, 13 March 2022 (UTC)

"Must not contain any wiki markup"

re https://wiki.openstreetmap.org/w/index.php?title=Template:ValueDescription/doc&curid=48108&diff=2280229&oldid=2278619 @Maro21:

"Must not contain any wiki markup" - why? What is the reason for that? Mateusz Konieczny (talk) 07:29, 9 March 2022 (UTC)

This isn't my idea: Data items#Tag_keys, I've just copied it to the right place. The reason is that the text in the description field is and may be used by different applications, for example iD displays these descriptions. maro21 22:10, 9 March 2022 (UTC)
This described data items. This does not mean that OSM Wiki infoboxes are obligated to follow that Mateusz Konieczny (talk) 05:52, 10 March 2022 (UTC)
The text from the description is copied to a data item. maro21 14:25, 13 March 2022 (UTC)
Why it should affect OSM Wiki in any way? Mateusz Konieczny (talk) 07:57, 16 March 2022 (UTC)
Coz I think it's good to have the same descriptions in both infobox and data items. The link to a tag or key page can be marked by using: tag:building=yes or key:landuse which will display as a link in the infobox. maro21 20:48, 19 March 2022 (UTC)
I also wonder why the way newer definitions from the data item description text is used for the old establish info boxes. This also applies for Should [...] end with a period.. Period at the end isn't necessary for me. My proposal is way around to change the data item description text definition to the infobox description text definition. --MalgiK (talk) 12:15, 10 March 2022 (UTC)
I think it documented the way how the descriptions had been written then. What's wrong with dots? Why don't you like them? maro21 14:25, 13 March 2022 (UTC)

Examples in documentation

The documentation of this template mentions many examples, like:

{{Description
|type=value
|key=amenity
|value=police

or

{{Description
| type          = value
| key           = dessert
| value         = cheesecake

which are technically correct, but we don't use this template directly, but as a supertemplate for {{KeyDescription}} and {{ValueDescription}}. Would it be ok if I delete these examples from here to avoid fragmenting data and keeping the same things in different places? maro21 14:47, 13 March 2022 (UTC)

add image=none

There should be possible to add the value "none" to "image=" so it won't request missing image - many tags are abstract, especially "ref:" tags, so they will never have any image. maro21 21:43, 19 March 2022 (UTC)

display title

@Wynndale: [1] something is still wrong after your today's changes. While editing there is "Warning: Display title "Template:Tag:shop=convenience" was ignored since it is not equivalent to the page's actual title." maro21 19:46, 15 April 2022 (UTC)

Sorry about that, fixed now. Pages with underscores were also affected. --Andrew (talk) 20:31, 15 April 2022 (UTC)

Website and URL pattern

I've just added two parameters, |website = and |url_pattern =, for keys which relate to a specific website. You can see them in use on Key:openplaques_plaque, but the labels are not displaying properly. Can someone help, please? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:29, 1 April 2014 (UTC)

I've fixed what you were trying to do - there's a really painful interaction between template parsing and whitespace, which is where {{If}} comes in, and additional entries were needed in {{DescriptionLang}} - but I have a feeling that there's going to be some different views as to whether it's a good change. On one hand, there's not going to be many keys which have a website/database dedicated to them, I guess, which suggests the information should go on the description page, rather than the description box. Thereagain, it's a pattern which could be applied to other keys, giving a standard way to capture the way of tying a value to a URL. I'll leave it to others to comment. Moresby (talk) 17:25, 1 April 2014 (UTC)
You asked for a comment. My thought process went as such: (1) Neat idea, (2) but this would only be needed for a few keys so perhaps just put it in the page's general text, (3) on second thoughts having it in the template allows data users to get at the data more easily. In conclusion, I'm in support of Andy's changes. For a bit more context see this mailing list post: https://lists.openstreetmap.org/pipermail/talk-gb/2014-April/015953.html Btw thanks Moresby for all your recent work on the template. --RobJN (talk) 19:20, 1 April 2014 (UTC)
Putting it into a separate template would still allow automatic extraction, though? In the main infobox, it feels like too much of a niche entry to me, since all the other entries are really core facts. After all, URL patterns are probably not really interesting for most readers. --Tordanik 15:24, 2 April 2014 (UTC)
Providing general readers with the originating website (surely a core fact) and URL pattern helps them to source the data. That's a good thing, right? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:01, 2 April 2014 (UTC)
From the perspective of a general reader, the originating website is already clearly visible from the introduction text, typically in the first sentence. As for the URL patterns, I think a textual "how to map" description is more helpful than some regular expression. Also note that for some tags, e.g. wikipedia and wikidata, the value is obtained more easily by copying the page title rather than manipulating the URL.
In the spirit of compromise, though, how about stating "External reference" somewhere in the infobox (perhaps in the Group Section? it is definitely a tag classifiction), with a "show details" like the current tools list? --Tordanik 19:18, 2 April 2014 (UTC)
I do not like adding these parameters as they are too specific to be included here. Chrabros (talk) 00:36, 3 April 2014 (UTC)
Agree with above. --Władysław Komorek (talk) 07:14, 3 April 2014 (UTC)
Thank you for fixing the template(s). This information definitely needs to be in a template, so that it is machine parsable. I favour putting it in the infobox, not least so that people can see whether or not a key includes a value that is intended to be looked up online. It could perhaps go nearer the bottom of the infobox, if the current position is too prominent. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:52, 2 April 2014 (UTC)

Redirect undone

I've undone the recent redirect if this template to a user-space version, since that did not seem to have been kept in sync with recent developments here, such as the URL and URL pattern attributes and tracking category. See above section. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:04, 17 April 2014 (UTC)

These additional attributes appear to be controversial, however, and there has been no new input for the past two weeks. Allowing for this template standardization to happen is another reason to bring that discussion to a conclusion. --Tordanik 00:56, 18 April 2014 (UTC)
I prefer Moresby's template (for English tags) over URL and URL pattern. So I believe that it would be better to keep Moresby's template and try to convince him to add these to his templates instead of reverting. Chrabros (talk) 06:45, 18 April 2014 (UTC)
Thanks Andy, Tordanik and Chrabros. I don't really want to take one side or the other in the "should these elements go into the description box" discussion, so I've put the functionality into the new boxes simply to match the current template. If there's a consensus to leave it in or take it out, I or someone else can make any necessary changes. That done, I've put the redirect back again. Moresby (talk) 15:41, 18 April 2014 (UTC)
That's great, thank you. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:30, 18 April 2014 (UTC)
I don't think you can avoid taking sides by effectively adding these fields to dozens of templates that didn't have them before. Regardless, it appears we need to have that discussion again at User_talk:Moresby/Description#Website_and_URL_pattern. --Tordanik 20:13, 18 April 2014 (UTC)
You're right - there's no way to take neither side completely, if I'm going to continue to take this work forwards. Given the options, this looked like the path of least resistance: this affects only two pages at this point, Key:openplaques_plaque and Key:openplaques:id, and the remaining hundreds of pages look just the same as they would have been without this addition. I've said that if there's a consensus, I'll happily implement it; also, if anyone wants to have an edit war, go ahead, just please don't break the templates in the process. I just don't want an as-yet-unsettled difference of views to stall a bigger task. Moresby (talk) 20:43, 18 April 2014 (UTC)

Website & url_pattern, redux

What are the substantive objections to these parameters? A prose description as suggested above, will not be machine readable. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:20, 18 April 2014 (UTC)

Machine readability can be achieved even if this is not included in the infobox, and I never meanted to argue against a machine-readable solution either. Therefore, the focus on the discussion should be on whether and how to present this information to a human audience.
Keeping this in mind, I think that including these facts in the infobox is just not helpful enough to the typical reader to justify four more lines. Furthermore, such rarely used parameters would cause the infoboxes on different pages to look very different, reducing visual consistency. Finally, I believe that people without technical background might not easily understand the "url pattern", so even leaving space concerns aside, the inclusion could create confusion rather than being helpful.
One way to address these problems would be to reduce the space this information takes up, e.g. by using my suggestion above (integration into group section) to limit the additional number of lines to 1, and keep the more technical data somewhat hidden. If we cannot agree on a solution along these lines, then I don't see a good alternative to an entirely separate template displayed towards the bottom of the page. --Tordanik 22:46, 18 April 2014 (UTC)
I agree with Tordanik. Chrabros (talk) 03:42, 19 April 2014 (UTC)
I also agree with Tordanik. This feature is too rarely used to justify adding complexity to this template (which is used pretty much everywhere). Creating another template for url_pattern and related features would not only keep it machine readable, it would make it even more flexible. --Jgpacker (talk) 01:03, 24 April 2014 (UTC)
There are not four new lines, but two (one for each parameter). If desired, they could be moved lower in the infobox. Infoboxes using them would not look "very different" to those not; the difference is relatively minor. We can link the "URL Pattern" label to an explanatory page. I'm not sure what you mean by "integration into group section" (please explain), but hiding data is not a good idea; it leads to people failing to enter or update it. that said, I'd like to see more people's views on this; do we have somewhere to flag up such discussions? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:20, 19 April 2014 (UTC)
In your openplaques example, there are even 5 new lines (in the visual output, not the source code): "Website", the URL, "URL Pattern", the pattern (2 lines). With shorter patterns, there would still be 4 lines.
What I meant with Group integration: There is a "Group" heading in the infobox, for your openplaques example this currently contains the "Historic" classification. My suggestion would be to additionally display an "External reference" (or similar) classification if the website and/or url_pattern parameters are filled in. The url pattern and website should not be displayed normally, but should be revealed by interacting with the "external reference" label, e.g. by hovering over it or clicking on it.
If you want to get more people involved, you could try the "Wiki Team" subforum on forum.osm.org. Not many people are active there either, but it could still get a few more eyeballs onto your suggestion. --Tordanik 10:26, 20 April 2014 (UTC)
I've posted neutrally-worded pointers there and in a couple of other places. I'm going to be mostly offline for a week; let's wait and see what others think, and pick this up when I return. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:24, 21 April 2014 (UTC)


Documented values

Hi, the new feature "Documented values" seems not to work very good. Please see leaf_type=*. When introduced this tag had 4 documented values which was OK. Then I have translated it to Czech and it reports 8 documented values now. This is little bit odd. I do not think that translations should be counted as a new values. Are you able to fix this? Chrabros (talk) 07:32, 11 June 2014 (UTC)

I also noticed this problem. I agree it can be a little confusing. --Jgpacker (talk) 20:34, 11 July 2014 (UTC)
Seems to work now after someone split categories into separate languages @Chrabros:, @Jgpacker: - is it still a problem? Mateusz Konieczny (talk) 11:30, 25 January 2021 (UTC)
Resolved: no known examples of breakage Mateusz Konieczny (talk) 22:57, 1 May 2022 (UTC)

Deprecation of parameter "seeAlso"

Usually the wiki page already has a "See Also" section, which tends to be more informative than what the content of the parameter "seeAlso=" could be (because it has more space to explain why other pages/tags are related). Tools like taginfo derive related tags from the tags linked on the page's content, so as far as I can see, this parameter isn't being used, and doesn't really seem useful by itself. That's why I propose we mark this parameter as deprecated on this template, so no one feels obligated to add it, unnecessarily duplicating information already shown in the page. Oh, and I only am proposing this after using this a couple of times, and seeing no benefit on this parameter. --Jgpacker (talk) 20:31, 11 July 2014 (UTC)

I quite like seeAlso section. It seems to me very easy to read and sometimes useful. I wouldn't deprecate it. Chrabros (talk) 06:58, 14 July 2014 (UTC)
I prefer the traditional "See also" section. As an infobox parameter, this can get quite large and inflates the size of the box, pushing images and similar content too far towards the bottom of the page. The "See also" section also allows adding a description to the link, which is not possible in the infobox. It's ok if people want to keep it around, but I'm not a fan. --Tordanik 19:49, 15 July 2014 (UTC)
Small section in infobox is good place to link page with other tags. Use bigger section if you need to post external links. Don't move tags is infobox. Xxzme (talk) 19:58, 15 July 2014 (UTC)
So what do we do now? Users are starting to simply copy all tags from the "See also" section on the bottom of the page into the infobox, without any explanatory text. I still believe that the seeAlso parameter shouldn't have been added. The infobox needs to be used sparingly, only showing the most important information. --Tordanik 20:21, 26 March 2015 (UTC)
I agree that it is pointless and should not be present but I am not bothered enough to deal with removing it Mateusz Konieczny (talk) 22:29, 23 February 2022 (UTC)

Removing parameter "lang="

As far as I can understand, the parameter "lang" from this template and {{ValueDescription}} are completely unnecessary right now. The language is already automatically inferred from the page's prefix, so it doesn't need to be manually specified. Anyone against removing it from the documentation, and perhaps updating the code to simply pass the value of {{Langcode}} to {{Description}} ?--Jgpacker (talk) 19:58, 29 August 2014 (UTC)

OK, The language bar is unnecessary on the template itself due to internationalization; In this case is it technically possible to make it disappear from the top of the page "Template" without harming the internationalization function? I do not know how to do it! --Gnrc69 (talk) 15:40, 26 November 2016 (UTC)
No the language pbar is necessary and part of the generated content, because key description pages are themselves translated, and need this bar !
This is not related at all to the internationlisation of the template itself: it just shows that a language bar will be displayed (nont autotranslated templates should place their navbar across template version in their doc page), not above the example display (which is used as a "safety" test for edits when previewing any changes in templates: we should avoid "includeonly" sections for templates, except for the generated autocategorization of pages including the template, or if the current code still has no safe mode for previewing, and tests are fully integrated in the doc page). — Verdy_p (talk) 18:36, 26 November 2016 (UTC)
Which key description pages need this parameter? Mateusz Konieczny (talk) 22:58, 1 May 2022 (UTC)

"May Be Used On Areas" + "Should Not Be Used On Relations" -> What About Multipolygons?

Considering a multipolygon relation is meant to be a stand-in for a closed way for any area-feature, I suggest modifying this template slightly. If onArea=yes but onRelation=no, currently the key description box says "should not be used on relations"; perhaps it should say "should not be used on relations (except multipolygon relations)" or "may be used on multipolygon relations". Vid the Kid (talk) 20:54, 27 February 2015 (UTC)

I'm not sure. I think this would add to the confusion. The idea is that multipolygon relations are areas. We don't say "should be used on ways (except on closed ways)" when we have the attributes onArea=no and onWay=yes. --Jgpacker (talk) 21:36, 27 February 2015 (UTC)
Perhaps it would be less confusing to change the mouseover description of the area icon to "may be used on areas (i.e. closed ways and multipolygons)"? --Tordanik 09:49, 28 February 2015 (UTC)
I like this idea. Maybe it could be and multipolygon relations instead of and multipolygons. --Jgpacker (talk) 14:30, 28 February 2015 (UTC)

Or maybe it should be like this:

  • onNode=
  • onWay=Yes (as in an open way)
  • onClosedWay=
  • onArea=Yes
  • onRelation=No
  • onMultilinestring=
  • onMultipolygon=
  • onParent= (also known as a Super-Relation).

--EzekielT, 10:35, 17 July 2017 (UTC)

Clearly not needed at all. — Verdy_p (talk) 11:17, 18 July 2017 (UTC)

Some things can only be mapped as a closed way as opposed to an open way; e.g. circular barriers. Maybe there are such examples in which a key or tag may be used on multipolygons; but not normal relations?

--EzekielT, 13:14, 18 July 2017 (UTC)


Translate taginfo title attributes

Hi, Is it possible to translate the taginfo title attributes where it says how many times the feature is used? The RedBurn (talk) 09:16, 14 March 2018 (UTC)

This is not made directly by this wiki but by an extension ({{#osmtaginfo:||key=*|value=*|rtype=*}}) that embeds the Taginfo box within an "IFRAME" loaded separately of the wiki page, from the external taginfo site.
And for now there's no way to instruct that external website to format the rendered content in a specific language using an additional "lang=*" parameter.
So the "#osmtaginfo" just returns an IFRAME requesting the HTML from "//taginfo.openstreetmap.org/embed/key?key=*" or "//taginfo.openstreetmap.org/embed/tag?key=*&value=*" and does not transmit any language parameter; taginfo will return the HTML only in English...
This is a request to do to TagInfo site authors to add support for the parameter, and then to ask to the "#osmtaginfo:" extension so that it transmit the language parameter.
For now what is displayed is similar to this web page: "https://taginfo.openstreetmap.org/embed/key?key=place&lang=fr" (note that it is not translated at all even if there's an attempt to transmit a lang=fr parameter to ask for French, the result remains in English only, even if the Taginfo site has support for translations, but not for this "embeddable" format) — Verdy_p (talk) 13:58, 14 March 2018 (UTC)
Thanks for the very useful info Verdy_p! I've filled an issue there: https://github.com/taginfo/taginfo/issues/224 The RedBurn (talk) 08:57, 15 March 2018 (UTC)

Double URL encoding in Taginfo links

Regarding keys including colons, we have the issue that the taginfo URLs are encoded twice (already reported here https://forum.openstreetmap.org/viewtopic.php?pid=743592#p743592). I could not find the correct spot to fix it, but maybe @Yurik: can help? --Tigerfell This user is member of the wiki team of OSM (Let's talk) 13:20, 29 March 2019 (UTC)

@Tigerfell: fixed. --Yurik (talk) 19:46, 29 March 2019 (UTC)
Thanks. Great that we can count on you! --Tigerfell This user is member of the wiki team of OSM (Let's talk) 07:49, 30 March 2019 (UTC)

Add alt-text to small images used as links

Could we please edit the template to include alt-text for the small images like the gray and red pencil shown to edit Wikibase items and the proposal link, and to show if onNode, onWay and onArea etc are yes or no? Right now, if you try to view wiki pages without loading images, these features are invisible. This would be important for usability by blind and limited-vision users, and it will also help users like myself who are on expensive metered internet connection and like to avoid loading images unnecessarily. I believe alt-text is best, but something that also shows on hover-over would also work. --Jeisenbe (talk) 12:13, 4 August 2019 (UTC)

conflictswith

What about a `conflictswith` property which specifies with what key/tag combination the key must not be used with? Yurikbot could then use that data to populate and sync Data Items. --Valor Naram (talk) 12:37, 28 December 2019 (UTC)

The template already reacts on https://wiki.openstreetmap.org/wiki/Property:P44 defintion on data items but I don't know how to set up this directly on template Fanfouer (talk) 20:51, 12 January 2020 (UTC)
@Valor Naram: Can you give some examples where such field would be useful? Mateusz Konieczny (talk) 08:49, 29 October 2020 (UTC)
@Mateusz Konieczny: For example: You shouldn't tag Tag:diaper=no and Tag:changing_table=yes together and generally absent from using Key:changing_table and Key:diaper together. But also combining Key:playground: and Key:playground (note the : char missing there) is toxic for data users and customers. Although they are similiar, they do not mean the same. --Valor Naram (talk) 17:55, 31 October 2020 (UTC)

Applicable jurisdiction

Some keys apply only in a single country or other jurisdiction. Can we add a parameter for this? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:12, 9 April 2020 (UTC)

Do you have some examples? --Jeisenbe (talk) 12:32, 9 April 2020 (UTC)
Key:ref:NPLG:UPRN:1 Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:23, 9 April 2020 (UTC)
I would suggest to use the techniques explained at Data_items#Storing_Geographical_Differences to store the information in Data items first and append the template to display this information on the wiki page in a second step. The advantage is that you avoid a multi-value parameter and keep the translations in sync via data items but the disadvantage is that the information is not available on the wiki page itself. I do not know if this approach is feasible though. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 08:34, 10 April 2020 (UTC)

Add category listing English language pages loading content from data items

Standard practice on English-language pages is to specify infobox template on Wiki Page rather than to load content from data items. I propose to create a category listing pages where anything is loaded from outside wiki page (from data items), so that such cases can be fixed. It would be done for English pages and potentially also other languages where there is no consensus to use data items Mateusz Konieczny (talk) 08:46, 21 June 2020 (UTC)

Standard practice on English-language pages is to specify infobox template on Wiki Page rather than to load content from data items.

Is there a standard practice? As far as I can see, there are some pages that use information from wiki pages and others relying on data items. I can not see any consensus. I am also strongly against changing pages not to use data items. I know that there was no consensus to introduce them, but changing anything back now is no better IMHO. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 10:56, 21 June 2020 (UTC)
There was no decision to add information to the pages. What happens is that someone edits the data item, and then suddenly the information on the page changes. It's quite possible that the editor of the data item does not even realize that the infobox has changed.
It's also a problem that people like Mateusz Konieczny, who try to maintaine the Tag: and Key: wiki pages as the standard documentation, are unaware that the infobox is suddenly showing new information. No watchlist is going to show these changes, unless you watchlist all the relevant data items. --Jeisenbe (talk) 20:08, 22 June 2020 (UTC)
There was never consensus, agreement or clear support to replace any part of OSM Wiki pages by data items. There was support for enabling data items, but it was never clarified how it would be used. Also, note that I am not proposing to stop using data items - I am proposing to only allow monitoring when it happens. Mateusz Konieczny (talk) 21:04, 22 June 2020 (UTC)
Translating wiki content, I constantly have the problem of diverging translations. For me, it is a great help, that there is only one place where you can change the information. I can accept that some users prefer to watchlist wiki pages over data items, so I think we agreed on leaving everything as it is and append the existing information with data items originating partially from the import process. replace any part of OSM Wiki pages by data items @Mateusz Konieczny: Please explain what was replaced? As far as I can see, all current input is taken into account by the template. Only data missing in some translations is taken from the data item. There is a general agreement not to remove the input parameters. I am proposing to only allow monitoring when it happens I understand, but I think your suggestion will not make the situation better for the reasons mentioned at the beginning of this comment. Please also consider tags with no English description. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 22:05, 23 June 2020 (UTC)
@Tigerfell:"Please explain what was replaced?" - Infoboxes display if no parameter is specified - what is quite confusing where someone removes incorrect parameter and it is not disappearing as now incorrect part of data item is displayed. Mateusz Konieczny (talk) 16:43, 18 August 2020 (UTC)
Okay, but that is an invitation to update the data items, too. That helps maintaining some consistancy IMHO. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 12:16, 18 September 2020 (UTC)
Only if you know why it happened this way. What worse, removing wrong data from data item has no immediate effect. I suspect that number of people who understand what happens is quite low. And the worst part is that someone may add gibberish by editing data item and you get not warning... Mateusz Konieczny (talk) 07:40, 19 September 2020 (UTC)
@Tigerfell: "That helps maintaining some consistancy" note that you need to manually spot such leaks of an incorrect data. Automatic listing where data items are silently copied into infoboxes would allow to verify all of them rather than spot them months or years later Mateusz Konieczny (talk) 08:04, 22 October 2020 (UTC)
I agree with @Mateusz Konieczny:, this is a serious problem. There are a small number of active wiki users who make sure that the pages for common tags and keys are not vandalised or accidentally changed to redefine the meaning of important features in OpenStreetMap, and many of us rely on the watchlist items to notice when an article has changed. It's not practical to watch all the data items, because these change 10 to 20 times more frequently, when every anyone adds a new translation or makes an edit in another language, and because each small change is listed separately. But now that the infobox pulls in data from the items, the "authoritative" text of a page can suddenly change without warning.
The best solution would be to no longer pull in information directly from the data items onto the English language pages. --Jeisenbe (talk) 04:01, 30 October 2020 (UTC)
Your suggestion does not solve the problem with vandalising users, it just keeps it out of English language pages. We have some additional 100 languages in this wiki and iD pulls its data from data items, not from the pages. I do not see how your approach addresses this. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 17:10, 29 December 2020 (UTC)
ad nonEnglish: I am anyway utterly unable to recognize vandalism/damage in non-English edits, except the most blatant one. But if I am forced to look at all edits at once then I will become unable to monitor also English ones. Mateusz Konieczny (talk) 18:19, 29 December 2020 (UTC)
ad data items and iD - if noone is capable of watchlisting data items (I am not going to do this), and it is causing issues then iD should not use data items. Exporting data from infobox parameters is not so hard Mateusz Konieczny (talk) 18:19, 29 December 2020 (UTC)
And yes, I have position "I am not interested in watchlisting, monitoring or using data items - and I do not want to be forced to do this" Mateusz Konieczny (talk) 18:19, 29 December 2020 (UTC)
BTW, I ended writing script that compares data items and infobox parameters, so I sort of monitor data items right now Mateusz Konieczny (talk) 18:19, 29 December 2020 (UTC)

Examples of silent damage caused by nonsense in data items

https://wiki.openstreetmap.org/wiki/Key:addr:place was listing "Requires: addr:city=* addr:street=*" in infobox what is complete nonsense. addr:place=* is used for example whee no street names are assigned! It was silently added from data item Mateusz Konieczny (talk) 08:00, 22 October 2020 (UTC)

This specific damage was temporarily fixed in https://wiki.openstreetmap.org/w/index.php?title=Item%3AQ44&type=revision&diff=2052462&oldid=2004659 Mateusz Konieczny (talk) 08:01, 22 October 2020 (UTC)
Completely nonsense "implies", added by bot, supposedly based on a Wiki page (it was not based on a wiki page): https://wiki.openstreetmap.org/w/index.php?title=User_talk:Yurik&diff=prev&oldid=2078828 Mateusz Konieczny (talk) 18:19, 29 December 2020 (UTC)
tourism=information had confusing and pointless "requires tourism=information" shown until https://wiki.openstreetmap.org/w/index.php?title=Item:Q4804&diff=prev&oldid=2087824 Mateusz Konieczny (talk) 22:01, 9 January 2021 (UTC)
social_facility=group_home linked to "Group Home" rap duo https://wiki.openstreetmap.org/w/index.php?title=Item:Q6453&diff=2098683&oldid=2098682 Mateusz Konieczny (talk) 11:41, 25 January 2021 (UTC)

What should be done with pages describing prefixes?

Maybe a new template would be a good idea? Or a way to hide/reformat statistics? For example taginfo summary for Key:disused: is confusing and misleading, links to tools are also probably broken Mateusz Konieczny (talk) 08:48, 29 October 2020 (UTC)

Taginfo should show 0 uses for such prefixes. And I think we should move Key:addr to Key:addr: or don't name such pages with "Key". I think addr is not a key, but for example addr:city. maro21 00:20, 30 October 2020 (UTC)
You are correct, addr: is not a complete key, in the database it is going to be something specific like addr:housenumber. Usually we link to the page Address instead. A key is simply a string of any characters, and there is nothing special about a colon (":") by nature. Although many application developers are familiar with this being used for "namespacing" in other contexts (including this wiki), all database users have to custom-design code to handle this, if desired. So it would be best to address actual, complete keys in the pages like Key:addr:city, or redirect those to a general article which is not prefixed with Key:. --Jeisenbe (talk) 03:55, 30 October 2020 (UTC)
My current idea is to have Prefix:addr:, Prefix:disused: with separate Template:PrefixDescription Mateusz Konieczny (talk) 11:07, 26 January 2021 (UTC)
I support it. But I think we should discuss it first on Talk:Wiki, not here. maro21 20:37, 26 January 2021 (UTC)

Translating an existing page

If you like to translate a page into your language you just need to create a page for it for example De:Tag:highway=track. Once the page exist the link to this side will be seen on every *:Tag:highway=track site.

Do not edit this template to add the link to your translated page!

Why don't we put the "Other Languages" table into another template (allowing parameter 1 to overwrite the title), so that all the different templates use the same block? It could be used 1.) in other languages and 2.) on other templates… -- MapFlea 15:36, 12 November 2008 (UTC)
Yes, I also think it would be better to have a generic Template:Language! And like in Template:Language-mp (which should also be replaced) there should be no ifexist-tests. Whenever a translation-page exists can be seen by the color of the link. Parameters are not needed as we can use the {{PAGENAME}} variable. See mediawiki:Help:Magic_words --Phobie 15:58, 13 November 2008 (UTC)

Wikidata

Any thoughts on adding "wikidata=" to the template, similar to the recent changes adding it to Template:KeyDescription and Template:Description? --Frankthetankk (talk) 21:22, 29 August 2014 (UTC)

If we support the parameter there, it should be supported here, too. But first it would be advisable to actually document the new wikidata parameter properly. Currently an explanation is missing from the template description, only its existence is noted. And while I find the idea interesting in general, I would also like to see some examples on how to use it (and how not to use it). I don't think this is self-evident. (I also dislike the complete lack of discussion preceding its introduction, by the way.) --Tordanik 01:49, 30 August 2014 (UTC)
It’s been added to Key:bridge. The icon for missing translations can be fixed if it’s worth keeping. I can’t say I’m convinced yet.--Andrew (talk) 08:04, 30 August 2014 (UTC)
Indeed. That example already points to a problem: While it is sometimes possible to state that all OSM elements with that tag are an instance of some Wikidata item, it is not possible in other situations. For example, roads with bridge=yes crossing a man_made=bridge are not instances of "bridge". Furthermore, a lot of OSM tags don't represent an instance relationship with some class of objects at all, but are properties instead. So I doubt that mapping Wikidata onto OSM tags in that manner is feasible. --Tordanik 21:47, 1 September 2014 (UTC)
So far I do not see any new value of this new wikidata feature. Maybe someone could try to explain its purpose in better example than is Key:bridge. Chrabros (talk) 07:39, 3 September 2014 (UTC)
What is purpose of this parameter? I see plenty of edits adding it and I missing any use for it. At this point I recommend removing it. Mateusz Konieczny (talk) 12:28, 4 November 2017 (UTC)
I plan on removing this parameter. Is anybody opposed and able to explain purpose of this parameter? What is purpose of linking Wikidata entries from tag pages? How it can be used to improve OSM? Mateusz Konieczny (talk) 08:35, 3 January 2018 (UTC)
I am opposed to removing the wikidata parameter. Its purpose is that by clicking on the link one can quickly find more information that explains what the tag is about, at least it should be used in way that this is the case.
Wiki_Translation#Community_cohesion: "Unlike Wikipedia, we are not aiming to capture vast amounts of knowledge in the wiki." So what else than links do you want to use? I assume that most people who have added wikidata IDs here thought that this would be helpful for other users, so that not everyone has to search by himself.
There is not always a corresponding wikidata item available or there may be other problems in some or perhaps in many cases, then the parameter can be omitted (and I think the "Search Wikidata" link is dispensable in this case), but that's no reason to remove the parameter in general (like it would also not be great to remove the "Available languages" bar everywhere just because there are sometimes contradictory statements in different languages).
Please make more clear what exactly you are planning to remove: The link if "wikidata = Q..." is set, or the link to the wikidata query window if it is not set ("Search Wikidata"), or both? --Hufkratzer (talk) 17:52, 4 January 2018 (UTC)
"Its purpose is that by clicking on the link one can quickly find more information that explains what the tag is about" - note that wikidata entries and OSM tags rarely match perfectly. I would not rely on this kind of links to explain how tags should be used Mateusz Konieczny (talk) 20:55, 10 November 2018 (UTC)
"Please make more clear what exactly you are planning to remove" - link, "search wikidata" link and all "wikidata" parametres added on Wiki pages Mateusz Konieczny (talk) 20:56, 10 November 2018 (UTC)
I asked Geozeisig who is often adding this parameter for help as I am still unaware how and why this parameter is added and used Mateusz Konieczny (talk) 15:56, 2 January 2018 (UTC)
Geozeisig replied in https://wiki.openstreetmap.org/w/index.php?title=User_talk:Geozeisig&diff=1542792&oldid=1542485&rcid=&curid=50235 "Sorry, I do not know the purpose of this parameter". Mateusz Konieczny (talk) 08:35, 3 January 2018 (UTC)
I asked Pigsonthewing who added this parameter Mateusz Konieczny (talk) 09:58, 3 January 2018 (UTC)
Thank you, Mateusz. I would, of course, be opposed to removing this very useful feature. I'm not clear what the objection to it, other than "I don't understand it", is. Perhaps the lack of understanding is caused by the poorly-chosen examples ("cheescake"?!?). The example for "power = generator" is slightly better, because the Wikidata search returns a real item, Q131502. But even that seems to be conflated with Tag:power=plant. A far better example (one of many correct uses) is Tag:landuse=cemetery; where there is an explicit link to Wikidata's Q39614 item. There, once can see machine-readable metadata about cemeteries, and query Wikidata for items about cemeteries (or of sub-classes or super-classes thereof), which can be cross-referenced with those in OSM to check for matches and discrepancies. The use of links (URIs) to such data ("linked data") both on thsi direction and the reverse (from Wikidata to OSM pages) is exactly what Sir Tim Berners Lee, the inventor of the World Wide Web, calls for (video, with text transcript). It is vital that OSM is part of the web of linked data, if its full potential is to be realised. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:24, 3 January 2018 (UTC)
Could we please leave politics (and religion so to speak) out of this? Mateusz asked for the specific purpose of the parameter. 'Linking' in itself is not a purpose. The question is what kind of relationship this reference indicates. How is this reference used/supposed to be used? As the meaning and use of tags change how do you determine if a certain value of this parameter is correct of not? landuse=cemetery and amenity=grave_yard have the same wikidata value. Is this correct? waterway=river references Q4022 but waterway=stream does not. Is this correct? How does the mapper editing the wiki determine if it is or not? What would be the wikidata value for something like access=* or opening_hours=*? See also Tordanik's remarks above. --Imagico (talk) 15:17, 3 January 2018 (UTC)
I don't know about "politics and religion", because I used neither. I did though explain the purpose of including the links to Wikidata. What about you leaving out the snark and the assumption of bad faith? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:38, 3 January 2018 (UTC)
I referred to "is exactly what Sir Tim Berners Lee, the inventor of the World Wide Web" - claiming that some authority supports it, without decent confirmation is a poor argument. I am pretty sure that he would not support useless linking not giving any clear benefits Mateusz Konieczny (talk) 20:54, 10 November 2018 (UTC)
"what the objection to it" - iff it is not clearly useful then there is no reason to keep it in infobox Mateusz Konieczny (talk) 15:29, 3 January 2018 (UTC)
Fortunately, it is clearly useful, as I explained. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:38, 3 January 2018 (UTC)
Are you claiming that "machine-readable metadata about cemeteries, and query Wikidata for items about cemeteries" is needed so often by users of OSM Wiki that it deserves to prominently displayed in the infobox? Because it seems to me that such things will be done rarely, and it is as relevant as linking relevant Wikimedia Commons category, Wiktionary item, Flickr category etc. I see no reason to elevate Wikidata so high, it is not like OSM Wiki is about promoting this project Mateusz Konieczny (talk) 19:05, 9 May 2020 (UTC)
"machine-readable metadata about cemeteries" - how it helps doing anything in OSM? Mateusz Konieczny (talk) 15:29, 3 January 2018 (UTC)
Not everything in OSM, or the OSM wiki, has to "help doing anything in OSM". The purpose is to "help OSM's users". Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:38, 3 January 2018 (UTC)
"help OSM's users" for me is included in "help doing anything in OSM". So how this kind of "machine-readable metadata about cemeteries" (only sort-of related to OSM tagging scheme) helps doing this? Mateusz Konieczny (talk) 20:50, 10 November 2018 (UTC)
"query Wikidata for items about cemeteries" - how this link from infobox is helpful in making queries? In my experience main obstacle in making queries is figuring out syntax of SPARQL and searching for identifiers is easy. Also, https://www.wikidata.org/wiki/Q39614 anyway has nothing that would allow making Wikidata query that is not already present on https://www.wikidata.org/wiki/Wikidata:Main_Page. In addition, is it really common for users of OSM wiki to make Wikidata queries? Mateusz Konieczny (talk) 15:29, 3 January 2018 (UTC)

[Outdent]

From the Wikidata item at Q39614, the quickest and simplest way for a human to query Wikidata for an up-to-date list of items about cemeteries is:

  1. Select the "Discussion" tab
  2. Select "List of instances"
  3. Select the big blue "run" (right-arrow) button

[None of these links are available on Wikidata:Main Page.]

The above just ran for me, in under three seconds. No knowledge of SPARQL required; the query can also be modified using the "Query Helper" wizard. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:27, 3 January 2018 (UTC)

"query Wikidata for an up-to-date list of items about cemeteries" - so only usage is to make searching Wikidata easier? Why we would need it? What makes Wikidata so special that infobox needs a special link to search in this particular database? Mateusz Konieczny (talk) 21:00, 10 November 2018 (UTC)
The OSM linkages on Wikidata can already be quite useful to create automatic translations of most tags. Its probably a better idea to store the links on Wikidata which is a proper database rather than the OSM Wiki though. If there was some way this wiki could query Wikidata and automatically add links to Wikipedia, and images from Commons, it would be super helpful in the lesser represented languages --Planemad/Talk 08:06, 10 January 2018 (UTC)
As discussed in comments in this diary entry - "The problem with using wikipedia / wikidata for this is that the words that OSM uses to describe things often don't match the dictionary definition (in any language, even British English) of those things, even for basic things like "city"." Mateusz Konieczny (talk) 21:02, 10 November 2018 (UTC)

I don't think the "Wikidata" link adds anything useful for OSM mappers and I would be in favour of dropping it. Also, if there is no Wikidata link set, then currently the template displays a "search in Wikidata..." link which gives the whole "linked data" religion unnecessary prominence. The template has many optional parameters, and "wikidata" is the only parameter where, when it is missing, Wiki users are nudged in the direction of researching and adding it. This makes it look as if adding the "wikidata" parameter was a more valuable use of an editor's time than completing other missing bits of information. This is a value judgement that I oppose. --Frederik Ramm (talk) 16:02, 8 November 2018 (UTC)

This is what Mateusz already suggested above. The only purpose of the wikidata parameter mentioned so far except the self fulfilling linking of data are to find more information that explains what the tag is about and automatic translation - which as it has been explained do not work since there is no semantic identity between the tag and the linked to wikidata entry and the illusion of such identity is misleading for the mapper. Because of this an automatic translation based on the assumption this identity exists is bound to be faulty which rules out this application as well. Plenty of examples given above that illustrate this. So i also see no good reason to keep this. It does more damage by misleading mappers than it provides actually useful information (which essentially amounts to someone thought this wikidata entry is somehow related to this OSM tag). --Imagico (talk) 16:27, 8 November 2018 (UTC)
Now we have our own Wikibase there’s another problem. The Wikidata link has a database link (Q number) that is different from the Q number in our own Wikibase instance. The WMF developers were very un-keen on Yuri’s suggestion of us using a different prefix letter to distinguish the two. Getting rid of the Wikidata parameter would solve this.--Andrew (talk) 06:26, 9 November 2018 (UTC)

Another user asked on the craft page:

"What to do if there is more than one Wikidata counterpart implied with craft=*? There is "craft" - Wikidata:Q2207288 - but usage in OpenStreetMap also implies "skilled trade" - Wikidata:Q64506407.
; Options
  1. Note down all Wikidatas (with semicolon) even if that's not currently supported? (e.g. wikidata=Q2207288;Q64506407)
  2. Link to the literal expression?
  3. Put in the best match? (Here you could prefer "skilled trade", covering a wider range of usage than "craft".)
  4. Leave it empty? (How many percent of matching is needed? Better a link with 75% matching or no link?)
I'm undecided myself and tend to 1 or 2 for now. (Perhaps "skill" would have been a more universal key than "craft".) --Chris2map (talk) 07:41, 3 May 2020 (UTC)
This is another reason that "wikidata=" should not be used in the Description templates (which create the Infobox), because it usually does not work. --Jeisenbe (talk) 16:04, 3 May 2020 (UTC)
Bald statements that something "usually does not work" do not inform the debate: you need to say what you mean by "usually does not work", you need to give examples, and you need to say what you have tried to remedy the examples you give and how that failed. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:59, 3 May 2020 (UTC)
The sensible solution, missing from your list, is to either use a parent item on Wikidata, that encompasses both of the child items which cause you an issue; or to start a discussion on Wikidata, to ask the community there to resolve the issue. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:59, 3 May 2020 (UTC)
Though in this case, "craft" is the parent of "skilled trade" (and not vice versa as you have it) and is the correct item to use here. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:08, 3 May 2020 (UTC)
Because items on wikidata relate to real-world concepts, while tags in OpenStreetMap are used in particular ways which have developed over time, attempts to link to a wikidata page will not find a good match. An example is how landuse=cemetery and amenity=grave_yard were both linked to https://www.wikidata.org/wiki/Q39614 - "place of burial", however the wiki pages for those tags note that they are not identically: amenity=grave_yard is used for churchyards and other grave sites located next to a place of worship, while landuse=cemetery is generally used for burial sites that are not associated with a place of worship. Similarly, the key craft=* does not match the definition on wikidata: https://www.wikidata.org/wiki/Q2207288 "pastime or profession that requires particular skills and knowledge of skilled work" vs our definition https://wiki.openstreetmap.org/wiki/Key:craft "A place producing or processing customized goods". Notice that the wikidata definition is of a hobby or job and focuses on skills + knowledge, while the OpenStreetMap tag is a location and focuses on making or processing goods. But also "places that are widely accepted as shops should not be tagged as crafts". Comparing the German and English wikipedia definitions might explain why wikidata and OpenStreetMap don't match: https://als.wikipedia.org/wiki/Handwerk vs https://en.wikipedia.org/wiki/Craft - but it's also due to the fact that craft=* was accepted long after many things were tagged as amenity=* or shop=* or man_made=*. Reading the linked wikipedia articles on the wikidata page will not help mappers or database users to understand what the key is used for in OpenStreetMap. --Jeisenbe (talk) 23:43, 9 May 2020 (UTC)
Resolved: Appears to be resolved with Proposed features/remove link to Wikidata from infoboxes Mateusz Konieczny (talk) 22:38, 1 May 2022 (UTC)

native_value and native_key parameters

We have more and more active people in the mapping who do not speak English.
I suggest adding a parameter to the template for the key and value, such as native_key and native_value. This will allow us to search for the correct key in the user's language.
I'm not sure whether it is possible to write a template for "Category" that can automatically create a list of tags in the user's language, based on these new parameters. --Władysław Komorek (talk) 11:30, 16 March 2014 (UTC)

It would be misleading to suggest that tags are language-dependent. But there are ways to make a word in the native language available to search: You could either use the word in the translated page content, or add a list of RelatedTerm entries at the bottom of the page, containing all synonyms for the object in the native language. --Tordanik 13:58, 16 March 2014 (UTC)
But do not give it to the user, especially the novices, the list of available tags in his language. Create an additional category to the list of tags in the language in no way interferes with the use of the existing categories, but minimize incorrect tagging and show other possibilities for tagging people do not understand the English language.
One of the biggest problems in OSM is a misunderstanding of the importance of individual tags and their improper use. Google Translate does not give a correct translation. --Władysław Komorek (talk) 15:09, 16 March 2014 (UTC)
Wouldn't the translated version of Map Features be much better suited for newbies? Alternatively, you could work on Pl:How to map a; that page is like a dictionary that gives translations from words of your native language into tags. --Tordanik 18:23, 16 March 2014 (UTC)
We have translated the "Map Features" long enough and still have the problem with improper tagging. Nothing has improved. You wrote "Pl:How to map a, that page is like a dictionary", but it is not a dictionary and needs to be written and continuously updated.
Category is the easiest way to automatically creating the current list of translated tags.
Based on the discussion on OpenStreetMap Forum in Polish, new users are very unhappy with the lack of a list of tag names, understandable in their language. Most people are looking for the information based on Wikipedia, where they have categories in their native language. To use the search he needs to know, in advance, a specific tag name. Search of intrinsic tag is too time-consuming and discouraging them to continue mapping. That's why most new users only focused on adding a few POI. --Władysław Komorek (talk) 20:53, 16 March 2014 (UTC)
Perhaps I simply misunderstand what you are trying to do. But to me it looks as if you are trying to solve the following problem: A user wants to tag an object. He knows what such an object is called in their native language. He now wants to find out the tag for it.
But that problem can be solved with some of the suggestions I made above. If you add the word as a RelatedTerm to the page, for example, then the page shows up in the results when the user types the word into the search field. --Tordanik 22:09, 16 March 2014 (UTC)
I already have it. If you open a Polish tag, you'll see in a Polish template for ValueDescription or KeyDescription, equivalent to the key name and value name in the Polish language.
But this is not enough for the Polish newbies. Remember that often the same object can have different names. A similar problem, for example, have users in the U.S., when they are looking for a tag for the road and do not know that the tag for the road is called "highway". This is a big difference between seeking unspecified name and picking a name from the list. --Władysław Komorek (talk) 00:05, 17 March 2014 (UTC)

Should group name be added a language prefix?

In October 2015, this template has modified; a category name from 'group' is now automatically added a language prefix from 'lang' value. But this has caused another trouble.
For example, the page 'JA:Tag:railway=halt' already has a prefixed group name ('JA:鉄道'). So the category name has become 'JA:JA:鉄道' by adding language prefix automatically.
It can resolve if I change the group name to '鉄道', but it will cause another trouble; if a localized group name has same name to English version, the localized version of category Key descriptions for group "XXX" (created by Template:DescriptionCategories) can't exist independently because it duplicates with the English version.

There are two methods to avoid this trouble:

  1. The all localized group names should be added language prefix, and cancel to add language prefix automatically (by this template).
  2. Modify Template:DescriptionCategories to add language prefix to category name automatically, such as Key descriptions for group "ll:XXX". The all prefixed group names must be modified.

How should we resolve it? --Mfuji (talk) 16:56, 26 October 2015 (UTC)

Group names should not have any prefix. The categorization however is partly broken in languiages other than English as the stan dard template currently does not imply any language prefix for the category name. There are works to do to separate the localized group name and the category name (whose default is the group name, but still not necessarily translated).
There are many "groups" not working properly for sorting features,; and many red links there for missing categories or categories with mixed/random contents.
Only a few groups/feature are currently working almost properly but there are still issues before it can work completely and the solution applied on other groups.
This is work in progress (complicated by the fact that the Feature template has also some localized variants not working exactly like the English one (because the Engliush one is also defective and still ignores how to completely manage translations). — Verdy_p (talk) 12:50, 28 October 2015 (UTC)
In summary: for parameter group=*, just use a unprefixed feature name which will be displayed as is by the template (you can temporarily leave this name in English, but you can translate it to Japanese (don't forget to set lang=ja in the template): if you translate the term, the category translated to Japanese will be "Category:JA:<translated group name in Japanese>". When this category exists, the article will be sorted there.
If you have still not created the category, don't translated the group name (leave it in English), but you can still use lang=ja (the template will first look for "Category:JA:<untranslated group name in English>", then for "Category:<untranslated group name in English>" to sort your Japanese article "JA:<article name in English or Japanese>").
A few groups are being converted to sort them by language. A priori there's no longer need to use a localized version of "Template:ValueDescription" (which still uses the lang=* parameter, but soon you'll no longer even need the lang=* parameter as the language code will be autodetected for the article page name including the template).
Hope this helps. — Verdy_p (talk) 14:02, 28 October 2015 (UTC)
Group names are used in not only "Category:LL:<group name>" but for example key description's category as Key descriptions for group "<group name>" (without language prefix). Isn't it possible that multiple languages have (localized) group names accidentally and in conflict between category names of Key description? (This problem is, however, irrelevant to Japanese...) --Mfuji (talk) 17:37, 28 October 2015 (UTC)
Category:Key descriptions for group "<group name>" do not support any kind of classification of languages for now. All is mixed, and in fact most group names do not have therir own categories even in English. This scheme was added some time ago without any consideration about how it should be classified. I've not attempted to convert them with the languages bar, and prefixes compatible with Template:Langcode. In fact the scheme is not fixable for now, and I don't care much about them. For now it only works for English-only pages. There's a solution to develop, but if we keep that name in English, for other languages it will become Category:<Lang:><translation of:Key descriptions for group> "<group name>" and quoted group names will also be translated. Later it some categories will need to be merged (using soft-redirection templates like other translatable categories)
Note: I do not intend to translate the (technical) **tag** names, but "group names" / "feature names" (in mostly the same naming space as some groups are also isolated features) are not tags and are translatable.
A few groups have started to be translated in their categories (Sports, and Buildings), I using only these to finalize the translation scheme before going further for other groups. The problem is to manage the many legacy templates that have been translated using their own local schemes for specific languages (but that also don't work fully), without breaking all. There's a lot of cleanup work to do to collect everything and get the expected navigation. But with what I did, it cannot be worse than what there's now which is incoherent everywhere and full of red links for lots of missing categories or orphan categories. — Verdy_p (talk) 20:56, 28 October 2015 (UTC)
About your example category, you can look at what I did, but I've still not scanned all languages. It should be OK however for Japanese.
If you still have doubts, about what to do, use English only group names for now (even if this populates categories in mixed languages), they will be translated later. — Verdy_p (talk) 20:58, 28 October 2015 (UTC)
I personally never liked the group attribute exactly because it seems to have been added on a whim to the template, without a good way to use it. Besides this problem you mentioned, there are tags that don't have a well-defined group or belong to multiple groups. I think this parameters shouldn't be used at all, much less add a category. I remember that recently some users went around removing explicit categories from pages, "forcing" the use of this parameter (I don't think they did this out of bad faith, but a previous discussion would have been helpful). --Jgpacker (talk) 23:54, 28 October 2015 (UTC)
I see. I agree if it won't be needed to re-add namespace to group names. I also think the category name Key descriptions for group "<group name>" should be internationalized.
I also think that the group attribute isn't needed, because category can be used instead of it and more flexible. It is problematic (e.g. we can't use multiple group, and it may cause a problem I said), although there is only few benefit. I think it is better if important categories can be enumerated in the info box, instead of groups, then it will become much simpler and flexible. --Mfuji (talk) 11:37, 30 October 2015 (UTC)
I also agree that "groups" were designed only to refer to the name of main subcategories in the "Features" categories. For me they are just a few selected feature names (all translatable independantly of the technical set of tag, i.e. keys/values, used to implement them and that remain preferably in British English).
The bad thing about those "group=*" parameters is that they force the automatic inclusion in some categories not correctly designed an in fact never discussed. It is hard to work with all those Category:<Lang:>Key descriptions for group "<group name>" automatically generated. I would personnally only keep the category names based on the British English key names. But sorting features via the template is a bad idea, and it has in fact never worked correctly the way this was done, and it is not maintainable). — Verdy_p (talk) 13:07, 30 October 2015 (UTC)


Hi, I think, the "group categorisation" piece of code should be removed altogether from this template:

  • "because it seems to have been added on a whim to the template" I totally agree.
  • There is now a more flexible way to add tags to group-specific categories via Template:DescriptionCategories if you do want this kind of categorisation.
  • It doesn't seem to be very widely used: The subcategories of all the categories in "Category:Features/translations" contain a total of exactly 600 pages containing "Tag:" in their title.
The most prominent namespace is Pl:, totalling 280 pages. However, in the total Pl: namespace, only 36 Tag: pages use this template, the others still using Pl:ValueDescription -> no change.
The other two main users are JA: and Cs: at 110 pages each. Cs: is already using Template:DescriptionCategories for that, which means they don't need this code too.
JA: could be enabled in Template:DescriptionCategories to continue pointing to Category:JA:<Group> if wished. Mfuji, what do you think?

Cheers, Charel (talk) 21:31, 29 April 2016 (UTC)

Relation multipolygon and onRelation=no?

Discussion moved from Talk:Wiki

Hello, there is a debate (e.g. here) about whether a feature mapped as area will get onRelation=no or onRelation=yes. I had the impression, backed by many wiki pages, that multipolygon relations are an exception and are considered to be just areas. Therefore when a feature can exist as area or multipolygyon relation it gets onArea=yes and onRelation=no.

But user VerdyP claims that we have to set onArea=yes and onRelation=yes. I find this clumsy as multipolygon relations are areas and if we accept this idea then onArea=yes will imply onRelation=yes all the time so onRelation meaning would be not so clear any more.

Could you please state your opinion here?

Thanks.

Chrabroš (talk) 12:28, 14 May 2017 (UTC)

It has been the assumption for as long as I have been involved that onRelation, like onWay, specifically relates to relations that are not areas; that is the whole point of having a separate onArea flag. --Andrew (talk) 20:57, 15 May 2017 (UTC)
I agree with you that multipolygons fall under onArea, not onRelation. That convention is also documented on Template:ValueDescription, so I'm surprised that Verdy p isn't aware of it. --Tordanik 13:40, 21 May 2017 (UTC)
When and where was this agreed ? There has just been some proposals but no discussion anywhere, and many topics use onRelation=yes (including external tools) that do not have this subtle distinction. And I've seen people changing multipolyugon relations into very complex areas (single closed way) because their validator complained about this, and thinking it was invalid to have inner rings for holes and they dropped them, or removed a multipolygon made of several outser areas and replacing them by tagging multiple areas (closed ways) instead, meaning that they duplicated the same feature with two distinct very close locations such as a couple of buildings. — Verdy_p (talk) 17:21, 21 May 2017 (UTC)
Note also that you insist on this, then the icon for relations should be completely dropped everywhere (including for boundaries, and as well for turn restrictions as their real geometry is an oriented line even if it includes an optional via node). We have conflicting interpretations between the OSM representation (used by all external tools) and the effective geometry (which is very fuzzy, as almost all features could become a node, a line or a surface and there's no need to prohibit them). The definition on OSM of an area is a single polygon forming a single non-intersecting ring, it does not include multipolygons with holes or that at not fully connected and have several outer rings.
Nothing was really decided, someone jhust commented his opinion in an informal proposal that was never decided/voted. — Verdy_p (talk) 17:27, 21 May 2017 (UTC)

"But user VerdyP claims that we have to set onArea=yes and onRelation=yes. I find this clumsy as multipolygon relations are areas and if we accept this idea then onArea=yes will imply onRelation=yes all the time so onRelation meaning would be not so clear any more.".

Wouldn't it be easier to add separate parameters for multipolygons and closed ways; like this?:

  • onNode=
  • onWay= (as in an open way)
  • onClosedWay=
  • onArea=
  • onRelation=
  • onMultilinestring=
  • onMultipolygon=
  • onParent= (also known as a Super-Relation).

EzekielT (talk), 18:25, 20 July 2017 (UTC).

Why does the template provide a different % than taginfo?

For example; in leisure=garden; the template says "11.18%" for ways; but when you go to taginfo itself (https://taginfo.openstreetmap.org/tags/?key=leisure&value=garden); it says "0.09%" for ways.

For trees; the template says "90.02%" for nodes; but on taginfo (https://taginfo.openstreetmap.org/tags/?key=natural&value=tree); it says "7.35%". That is a massive difference! What's going on?

EzekielT (talk), 18:50, 20 July 2017.

Unless I'm mistaken, those are two different statistics: The template shows % of features with that key (e.g. 11.18% of ways tagged leisure=*), whereas the Taginfo page shows % of all features in the database. I agree it's confusing, though. --Tordanik 14:34, 21 July 2017 (UTC)

I was wondering if that was the case. Thank you :)! Maybe we should add % of all nodes, ways, and relations in the database; as provided by taginfo, to the template, too?

EzekielT (talk), 11:09, 21 July 2017.

That part of the template is included from an external source, so we (wiki contributors) can't change it. Would need to be changed in the code. --Tordanik 15:26, 21 July 2017 (UTC)

Add incompatibilities

This template shows useful combinations, implications but not incompatibilities which exist between some tags.
I mainly have concern with power=* for which power=transformer is incompatible with building=* or even power=plant shouldn't be used in combination of generator:*=*.
It's pretty sure many other contributors need such a classification. —Preceding unsigned comment added by Fanfouer (talkcontribs)

We could add a new property to the data items, and make both {{KeyDescription}} and {{ValueDescription}} support it. This way it will automatically show up in all languages the moment data item has it. I just created incompatible with (P44) for this purpose - try to add it to a few data items (e.g. update the power=transformer (Q5254) -- click "add statement" at the bottom to add P44 with the needed values. --Yurik (talk) 23:55, 6 March 2019 (UTC)
This is great ! Thank you :) Fanfouer (talk) 00:07, 7 March 2019 (UTC)
Nothing against the property, but I find it a bit confusing that this new property has to be edited directly on the wikibase page while the others that are listed under "Useful combination" etc. have to be added on the normal wiki pages in {{KeyDescription}} / {{ValueDescription}}. Why is this so? What are your plans with what is currently listed in the "combination", "seeAlso", "requires" and "implies" sections? --Hufkratzer (talk) 19:29, 7 March 2019 (UTC)
@Hufkratzer: the goal is to migrate all other properties to the data items as well, and remove them from the template parameters. The only reason we haven't done it yet is because TagInfo does not yet support data items, and instead tries to (often incorrectly) to extract that data from template parameters. The current system of having different values depending which language you are reading is clearly a problem that needs to be solved. --Yurik (talk) 20:39, 7 March 2019 (UTC)
AFAIK when editing a wikibase page directly it is not possible to add a meaningful changeset comment. I think this is a big disadvantage. Can that be changed? --Hufkratzer (talk) 21:19, 7 March 2019 (UTC)
@Hufkratzer: I think it is possible, just not with the standard Wikibase interface. We could implement our own gadget to customize the UI (might take a bit of effort, but doable). There are many existing Gadgets we could use as examples. In the meantime, there is always a talk page where we can discuss certain aspects of a data item (not ideal, but still much better than having thousands of conflicting parameters in different languages) --Yurik (talk) 21:37, 7 March 2019 (UTC)
P.S. I have made a request for this feature, please track it at T217873. --Yurik (talk) 00:34, 8 March 2019 (UTC)
"the goal is to migrate all other properties to the data item" - this is a horrible idea, for start that makes changeset comments impossible and makes editing wiki even harder. Mateusz Konieczny (talk) 07:57, 8 March 2019 (UTC)
@Mateusz Konieczny:, creating and editing a wiki markup page is far more difficult for novices than filling out a pre-made form. The moment data items were added to the wiki, we got 10s of thousands of description edits, often for the items that have no corresponding wiki pages (in that language). In other words, it is far easier to add a translation for a key/tag in a data item than to create a full blown wiki page in every language. On the other hand, having 10 translated pages with mismatching definition of an item (requires/implies/... params) has very low value, and is confusing. Plus it makes it nearly impossible to accurately parse - taginfo simply skips many of the broken ones, and noone else AFAIK even tries to parse these parameters. So yes, it is desirable to move these things to the data items, while keeping free-form text on the wiki pages. Note that the infobox is just the first step -- we also want to migrate tables of data (like a list tag values appropriate for a key) -- those should also not be copy/pasted between languages, but instead auto-generated from the data items.
The ability to add summary is a very valid concern, and I am looking into it, but I don't think a complete mismatch between languages/unparsable data and inability to add edit summary are the same level of problems (especially because we can work around it by discussing things on the talk page). --Yurik (talk) 17:36, 8 March 2019 (UTC)
OOjs UI icon check-constructive.svg Everyone, you can now add summaries to your data item edits. Enable it in the preferences - gadgets tab, and you can try it on the sandbox item. --Yurik (talk) 21:58, 16 March 2019 (UTC)
If I click save, enter a comment, activate another browser tab (in Chrome) and come back the comment box is gone and my change is saved without my comment. --Hufkratzer (talk) 18:56, 26 March 2019 (UTC)
@Hufkratzer: do you click "ok" or "cancel" after you click "save", or do you just enter a comment and don't click a button? I see many comments that you entered in sandbox history (funny too :)). --Yurik (talk) 19:21, 26 March 2019 (UTC)
The comment box disappears before I click "ok" or "cancel", I just activate another browser tab. --Hufkratzer (talk) 21:15, 26 March 2019 (UTC)
I think this is standard Chrome-specific behavior (no idea why to be honest) -- See [2] and [3]. A better solution would be to use OOUI dialog lib, maybe @Minh Nguyen: might know how to do it? --Yurik (talk) 00:19, 27 March 2019 (UTC)
P.S. Come to OSM slack to discuss. I'm @nyurik there. --Yurik (talk) 19:23, 26 March 2019 (UTC)
Wouldn't this be the appropriate place to discuss this gadget? --Hufkratzer (talk) 21:15, 26 March 2019 (UTC)
Different types of discussion -- Slack allows direct communication, a chat, much faster to figure out what is going on. Phab ticket is for bug planning -- unfortunately I don't think Wikidata team has it as a high priority item, so it might take some time for it to happen there. --Yurik (talk) 00:19, 27 March 2019 (UTC)

truncation of changeset comments

Another issue with the gadget for changeset comments: If a very long description is edited the changeset comment will be truncated because there is limited space which is occupied by the long description, see example --Hufkratzer (talk) 20:38, 16 April 2019 (UTC)


Where this template may be edited?

https://wiki.openstreetmap.org/w/index.php?title=Template:ValueDescription&action=edit has just {{#invoke:DescriptionFromDataItem|main}} Mateusz Konieczny (talk) 12:15, 25 April 2019 (UTC)

@Mateusz Konieczny:, I believe that {{Description}} is still used to define the layout of the infobox. I'm not 100% sure as I no longer really understand the templates since the Lua port, but the documentation of Module:DescriptionFromDataItem seems to confirm it. --Tordanik 14:01, 5 May 2019 (UTC)
I asked author of recent edit for confirmation Mateusz Konieczny (talk) 16:57, 29 May 2019 (UTC)
Thanks Tordanik, that is correct. {{Description}} is still used for all styling. --Yurik (talk) 17:12, 29 May 2019 (UTC)

Script errors based on input

There are some pages in the category Pages with script errors due to issues with the input I guess namely Ko:Key:wikipedia and Pl:Key:addr:place among others. I could not figure out what is wrong there. Any ideas? --Tigerfell This user is member of the wiki team of OSM (Let's talk) 16:16, 25 May 2019 (UTC)

Fixed the Ko:Key:wikipedia case -- it was actually an error in the template parameter - group was given as a link rather than a string, but now the code will handle it. --Yurik (talk) 23:17, 29 May 2019 (UTC)
@Yurik: - any idea what is happening in Pt:Tag:place=square? Mateusz Konieczny (talk) 18:12, 24 January 2021 (UTC)

Stop Feature pages with missing images for deprecated tags

I propose to stop requesting images for features marked as deprecated - see Category:Feature pages with missing images that has many image requests, many of them for unimportant deprecated pages where adding image to infobox is not useful. I proposed to remove them from this category Mateusz Konieczny (talk) 11:46, 8 June 2020 (UTC)

+1 --Tigerfell This user is member of the wiki team of OSM (Let's talk) 13:11, 8 June 2020 (UTC)

Add category listing English language pages loading content from data items

Standard practice on English-language pages is to specify infobox template on Wiki Page rather than to load content from data items. I propose to create a category listing pages where anything is loaded from outside wiki page (from data items), so that such cases can be fixed. It would be done for English pages and potentially also other languages where there is no consensus to use data items Mateusz Konieczny (talk) 08:46, 21 June 2020 (UTC)

Please see Template_talk:KeyDescription#Add_category_listing_English_language_pages_loading_content_from_data_items --Tigerfell This user is member of the wiki team of OSM (Let's talk) 10:58, 21 June 2020 (UTC)

place a page in the language specific category even if it doesn't exist

See for example Yue:Tag:building=garage. This page in Cantonese is placed in the English category Category:Parking because Category:yue:Parking doesn't exist. It should placed in the language specific category even if it doesn't exist. It would be easier to create missing categories from Special:WantedCategories, but now no one knows that such category is needed. maro21 16:29, 6 January 2021 (UTC)

Ability to specify whether direction matters for ways and areas.

Knowing whether a way's direction matters is important when using a tag, so I think it would be useful to point this out in this template for tags where it does. I don't have a good idea about how it could be presented though. --GoodClover (a.k.a. Olive, ) (talk) 13:08, 12 June 2021 (UTC)

Compare wiki description with British English version of data item

Unresolved

This template compares the description given as a parameter with the description given in the corresponding data item, and if they differ it shows a red warning. The wiki uses British English, but the template seems to compare the description given as a parameter on an English wiki page (British English) with the US English description in the data item. An example is hazard=horse_riders. I propose, to avoid wrong warnings, the template should compare it first with the British English description of the data item (3rd line), and only if this is empty with the US English version (first line). --Hufkratzer (talk) 18:04, 20 August 2021 (UTC)

Description should be the same in the infobox and data item. Data item should be a copy of the Wiki page. I fixed the description. maro21 16:52, 10 October 2021 (UTC)
This wasn't a fix. The data item has two different fields, one for US English (first line) and one for British English (third line). If I configure the preferred language in my OSM account to "en-GB", iD shows me the description from the third line (British English), if there is any entered, and this makes complete sense. If I configure the preferred language to "en" or to "en-US", iD shows me the description from the first line (US English). Because the wiki uses British English, the wiki description should be the same as the description in British English in the data item (third line). But the description in US English in the data item (first line) may be different from the description in British English (third line). In the example that I mentioned, the British description has to use the expression horse riders, while the US description has to use horseback riders. It had been like that and your so-called fix has made it wrong. There is a similar problem especially with all tags that have "centre" in their description. --Hufkratzer (talk) 19:05, 10 October 2021 (UTC)
Why do you assume that "English" is US English? If the Wiki uses British English, fields in the data item are also in British English because data item is a copy of the infobox. maro21 22:15, 10 October 2021 (UTC)
I have already explained above that there are two different fields in the data items and how iD uses them. Do you think it makes sense to use both of these fields redundantly for British English and none for US English? The wiki itself uses only British English, probably for historical reasons, but the OSM website also uses "en" for US English and en-GB for British English (see [4]). See also wikidata. --Hufkratzer (talk) 11:46, 11 October 2021 (UTC)
iD and website use American English as default English, Wiki uses British English, AFAIK. maro21 21:17, 12 October 2021 (UTC)

Multiple groups?

Can a tag be linked to multiple groups with this template? I tried several different ways but couldn't get it to work properly. Reason for asking is that designation=core_path can apply to both highways and waterways. Thanks. Casey boy (talk) 20:19, 5 February 2022 (UTC)

I don't think so. You should add other categories manually. There are many cases that a tag can fit into multiple categories. maro21 18:11, 26 February 2022 (UTC)

Include id-tagging-scheme link under "Tools for this tag"

I'm not sure how to approach this but it would be nice to include "id-tagging-schema" under "Tools for this tag" which links through to the specific field or preset json file, eg. https://wiki.openstreetmap.org/wiki/Key:mtb:scale:imba would link through to https://github.com/openstreetmap/id-tagging-schema/blob/main/data/fields/mtb/scale/imba.json. Given the importance of the id-tagging-schema for documenting and localising tags and values linking will make it easier for people working on tagging. --Aharvey (talk) 06:27, 18 May 2022 (UTC)

id-tagging-scheme is not well readable and people able to understand it well can also easily find relevant pages. Not sure is it useful to link on individual tag pages Mateusz Konieczny (talk) 08:51, 18 May 2022 (UTC)
Yeah true, but linking it will help make the OSM ecosystem barrier to entry a little bit lower. Ideally it would link to a guide frontend which then has source links, like nsi.guide is the frontend for the name-suggestion-index, but that doesn't exist yet. --Aharvey (talk) 11:00, 18 May 2022 (UTC)
Even if it would exist - infobox is not a place to link every single tool or resource. I think that improving https://taginfo.openstreetmap.org/tags/bicycle=no#projects and adding some tag specific link there would be a more viable solution Mateusz Konieczny (talk) 08:23, 19 May 2022 (UTC)
Linking to https://github.com/openstreetmap/id-tagging-schema/blob/main/data/fields/mtb/scale/imba.json would be impossible using wikicode. It could be done in Lua, but that makes much more time to write a parser. maro21 20:48, 18 May 2022 (UTC)