Template talk:Description

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)

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)

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)

I would just document key=value combinations where such value can be used, as no value can be used for all keys @Jojo4u: Mateusz Konieczny (talk) 08:41, 3 August 2022 (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 is used for node objects and is used for 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 is used for way objects and is used for 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)

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)

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)

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)

Templates without image parameter

Resolved: now changed Mateusz Konieczny (talk) 08:41, 3 August 2022 (UTC)

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)

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)

image=none would cause other issues. If we want to suppress Category:Tag and key pages with missing images for these I recommend to use a new parameter, like noimage=yes. --Chris2map (talk) 18:11, 18 March 2023 (UTC)

Website and URL pattern

Part 1

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)

Part 2

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)

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)

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)

I see that it is used on documentation pages itself, I guess that it is a good enough reason to keep it? Mateusz Konieczny (talk) 20:44, 4 August 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  (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  (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)

Note: there is also https://wiki.openstreetmap.org/wiki/Property:P44 nowadays. Not sure how often and how well it is used, for example https://wiki.openstreetmap.org/wiki/Item:Q464 has wrong claim that all noname=* conflict with name (noname=no is weird and pointless and should be eliminated, but does not conflict with name=*) Mateusz Konieczny (talk) 20:43, 4 August 2022 (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  (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  (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  (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  (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  (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)

And people are confused again, see https://wiki.openstreetmap.org/w/index.php?title=Talk:Wiki&oldid=2365463#Key:name_template_weirdness Mateusz Konieczny (talk) 20:41, 4 August 2022 (UTC)

Test categorization of pages loading content from data item

Resolved: --Chris2map (talk) 17:51, 6 June 2023 (UTC)

Recently categorization was added to the sandbox version for testing.
You can test it with following code on a page of your choice. If you add any content behind a parameter, the new (red) categories will disappear.

{{#invoke:DescriptionFromDataItem/Sandbox|main
|key=playground
|description=
|image=
|status=
|onNode=
|onWay=
|onArea=
|onRelation=
}}

@Mateusz Konieczny: --Chris2map (talk) 21:03, 12 March 2023 (UTC)

Following categories have been created:

• Category:Pages loading description from data item
• Category:Pages loading status from data item
• Category:Pages loading image from data item
• Category:Pages loading applicabilities from data item

--Chris2map (talk) 16:55, 17 March 2023 (UTC)

Good idea, thanks! I've already emptied three of these categories - images, description and status. Well, only main namespace; there are some user pages or templates where it is correct. Could you change this template to exclude user pages from listing? maro21 15:39, 14 April 2023 (UTC)

Thanks! I'm thinking about that, too. I'm just undecided whether it's more helpful to exclude certain namespaces or to deliberately not exclude them. --Chris2map (talk) 16:31, 14 April 2023 (UTC)

More helpful would be to exclude certain namespaces, like: User, User:Talk, Template, all other Talks probably too. Because it's ok when I test something on my user page, but when I add {{ValueDescription|key=shop|value=sth}}, my user page will be in a lot of categories. This applies to all categories added by this template, but I don't know where to write about it yet. maro21 17:32, 14 April 2023 (UTC)

Changed applying Category:Pages loading ... from data item to namespace 0 (main) only. [1] and

changed applying Category:Mismatched ... to namespace 0 (main) and 16+ (custom ones like language namespaces (DE, ES,...) or Proposal: (3000)) only. [2] --Chris2map (talk) 07:55, 15 April 2023 (UTC)

I've emptied all the categories! New pages can appear there, of course, because people edit. maro21 21:06, 31 May 2023 (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 (talk • contribs)

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)

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 [3] and [4]. 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)

• Is editing at https://wiki.openstreetmap.org/w/index.php?title=Module:DescriptionFromDataItem&action=edit editing this template now? But it seems to just extract data and I am looking for place where styling of this template is defined Mateusz Konieczny (talk) 12:16, 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)

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 [5]). 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)

I got it wrong above,, the OSM website uses both en.yml and en-GB.yml for British English and there is currently no en-US.yml, see here.

For the data items there is currently no convenent way to enter descriptions in US English, see Talk:Data_items#British vs American / US_English. Maybe it will be added, maybe not. What we currently have is a field for a description in British English. As long as that is the case, those descriptions in explicit British English (if they are entered) may differ from what is in the general English field and should take precedence when comparing with descriptions from the English wiki pages. The alternative would be to remove the field for British English in the data itejms and create a field for US English instead. --Hufkratzer (talk) 11:16, 28 May 2023 (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"

Resolved: Resolved by not adding this (remove this if you disagree with such resolving) Mateusz Konieczny (talk) 09:21, 26 June 2023 (UTC)

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)

Add category listing aliased status values

Ideally status=defacto or status=inuse or status=Approved would never be used, as it makes processing infobox data more complicated.

With status=de facto or status=in use or status=approved used instead.

Right now template code accepts such values, I propose to move toward rejecting it with listing pages where it happens as the first step.

I propose to modify Template:DescriptionStatus to start adding Category:Aliased status value or something similar where applicable.

@Angoca: who is likely interested due to https://github.com/taginfo/taginfo/issues/366#issuecomment-1180063844

Mateusz Konieczny (talk) 08:39, 3 August 2022 (UTC)

For the benefit of anyone reading this discussion: this problem goes away if you read the data items instead. --Andrew (talk) 14:10, 5 August 2022 (UTC)

Then you get other problems instead, like lower data quality and more complex accessing data (at least when I was writing my python script getting access to data in infoboxes was easier than to what is in data items, I gave up on parsing part of data items) Mateusz Konieczny (talk) 14:28, 5 August 2022 (UTC)

I went on and empowered Template:DescriptionStatus to categorize all pages with aliased status values. In fact all status values are captured if they are not one of these: | abandoned | approved | de facto | deprecated | discardable | imported | in use | obsolete | proposed | rejected | undefined | unspecified | E.g. if the first letter is upper-case. It is case sensitive. - The maintenance category is named Category:Unsupported status value for now. And Category:DE:Unsupported status value, Category:ES:Unsupported status value and so on. What do you think about that and the category naming? @Mateusz Konieczny and Angoca: --Chris2map (talk) 18:11, 1 June 2023 (UTC)

It would be good if a bot corrected this :) maro21 21:31, 1 June 2023 (UTC)

That would be nice! --Chris2map (talk) 05:45, 2 June 2023 (UTC)

Thanks! Mateusz Konieczny (talk) 06:26, 2 June 2023 (UTC)

Now the uppercase status values are tracked in a separate Category:Uppercase status value, Category:DE:Uppercase status value, Category:ES:Uppercase status value and so on. --Chris2map (talk) 21:07, 6 July 2023 (UTC)

Current categorization:

• Category:Unsupported status value (one category for all languages)
• Category:Uppercase status value with per language versions Cs- DE- ES- FR- JA- Pl- Pt ...

--Chris2map (talk) 15:12, 7 July 2023 (UTC)

@Kjon and Lenochod: Huge thanks to you for fixing all the hundreds and thousands occurrencies of unsupported, uppercase status values! Now there are no more English key and tag pages in Category:Uppercase status value. --Chris2map (talk) 07:40, 23 July 2023 (UTC)

Template without parameters cannot be processed by taginfo

If you enter a template without parameters, then taginfo cannot process such a wiki page and returns empty values of all data items. Applications and users will not be able to show data from taginfo in this case.
Issue github.com/taginfo/taginfo/issues/377 closed as before issue github.com/taginfo/taginfo/issues/248 dr&mx (talk) 16:38, 4 October 2022 (UTC)

This issue also has more severe consequences including that taglists are unusable unless every page has a long form page in the current language, which makes non-English Map features much less usable. --Andrew (talk) 17:40, 4 October 2022 (UTC)

"which makes non-English Map features much less usable" only where people blanked infoboxes and removed this info from OSM Wiki Mateusz Konieczny (talk) 08:57, 5 October 2022 (UTC)

even if someone broke the rules, it is better to make foolproof.
If at least one parameter is removed from the template on the page, then the user will see this parameter only on the wiki infobox, but not in taginfo
If taginfo could parse more data from data items, then there would be no empty data in third-party applications that use taginfo. And users would see up-to-date data on the Wiki page and in applications
another way is to completely abandon the data items so as not to update more than one source of information — dr&mx (talk) 15:57, 5 October 2022 (UTC)

This is nothing to do with infoboxes that fall through data items; it concerns languages where there is no long form documentation page at all (less likely in English; more so elsewhere) where Taginfo (and therefore taglists) will not display a description and the only way round is to use traditional “generic” templates and risk running out of server resources. Andrew (talk) 20:23, 5 October 2022 (UTC)

"it concerns languages where there is no long form documentation page at all" - in such case it can be (and should be) created. Mateusz Konieczny (talk) 08:10, 6 October 2022 (UTC)

…until the author of the documentation in Breton loses interest and out-of-date advice sticks there. Andrew (talk) 11:47, 6 October 2022 (UTC)

Data items suffer from exactly the same issue Mateusz Konieczny (talk) 03:29, 7 October 2022 (UTC)

we can define parameters that users need (eg description) and for wiki management (group for categories). how to find out the list of viewed parameters by taginfo? -- dr&mx (talk) 13:23, 7 October 2022 (UTC)

Bot for syncing description box entries and data item

We urgently need a bot to sync entries on the wiki page with the data item by copying the content in case of an edit from the one to the other in both directions, IMHO. Then we achieve consistency and are able to manage and monitor changes because the changes on the pages will be listed in RecentChanges and Watchlist. And as a result, once a page has been created in any language, it will also benefit from inputs and updates to the data items. – Who is able to code and set up such a bot? --Chris2map (talk) 17:08, 14 March 2023 (UTC)

@Chris2map: I could code it, but it seems that either deleting data from infoboxes is simply bad edit and should not be done or there would be needed (for some languages if any) agreement that parameters need to be restored. For which pages it would be useful to copy data item parameters back to OSM Wiki? Mateusz Konieczny (talk) 05:55, 21 May 2023 (UTC)

For all pages. I'm looking for a solution that we don't have to maintain or edit 2 places of the data. But I'm still in two minds wether it is more beneficial to store and edit the infobox data in the wiki page or in the data item. I tend to data items cause I like to have a data base structure for these facts of a tag. But for now, there are at least this two major disadvantages: No edit comments. No possibility to monitor only changes to a data item to a specific language (in recent changes and watchlist). – So I think if a bot is going to copy data from one to the other, we'll get rid of the inconsistency, at least. True, we have to check and maintain the edits and data. But we have to anyway. --Chris2map (talk) 08:50, 21 May 2023 (UTC)

Category:Mismatched image shouldn't list "Image:Abc_defgh.xyz"

Resolved: code was implemented to avoid listing --Chris2map (talk) 09:02, 21 May 2023 (UTC)

Hi there! Because maintenance Category:Mismatched image isn't helpful due to the quantity of member pages with image file notation with "Image:" instead of "File:" or "_" instead of " " (space), I figured out a workaround to use with {{KeyDescription}} and {{ValueDescription}} by adding

|image={{#if:{{{image|}}}|{{#ifeq:{{#explode:{{{image|}}}|:|0}}|Image|File:{{#replace:{{#explode:{{{image|}}}|:|1}}|_|<nowiki/> <nowiki/>}}|{{#replace:{{{image|}}}|_|<nowiki/> <nowiki/>}}}}}}

at the end of the #invoke command.

See User:Chris2map/Sandbox&oldid=2462389.

For an example see Sandbox&oldid=2462392. It isn't categorized in "Mismatched image".

What is your opinion and could I add it to {{KeyDescription}} and {{ValueDescription}}? --Chris2map (talk) 22:58, 10 January 2023 (UTC)

Maybe a bot could do the job... FrViPofm (talk) 10:48, 1 March 2023 (UTC)

I implemented code in Module:DescriptionFromDataItem to avoid putting a key or tag page in Category:Mismatched image in case of the differences in notation quoted on top. However I'd appreciate if a bot could eliminate those "Image:" notations. --Chris2map (talk) 09:02, 21 May 2023 (UTC)

Adding wikidata link to the boxes

Unresolved

(copied from Module_talk:DescriptionFromDataItem#Adding_wikidata_link_to_the_boxes)

Hi there,

There is a lot of tags (keys or values, e.g. landuse=orchard) with corresponding Element data (e.g. Item:Q4923) having a concept Wikidata value (e.g. Q236371). But the correspondance wikipage (e.g. Tag:landuse=orchard) does not show a link to this wikidata item ( e.g. [6]).

In the Infobox, Tools for this tag offers precious technical and historical links to the key|value, but not links to deeper the semantic, in spite of the available semantic tools.

It should be interesting to add such links in the Tools for this tag.

First : a wikidata link. It does not need to be a big one. A simple logo with a link, like I did here for example. A little tooltip with the localized label could be helpful.

And, I don't know if it is possible, when the wikidata item have links to wikipedia pages in different languages, a link to the wikipedia page (e.g. Verger) in the actual language, with a label, or with a logo and tooltip...

Thanks for your opinion and your skill. FrViPofm (talk) 11:30, 18 February 2023 (UTC), edit FrViPofm (talk) 11:31, 1 March 2023 (UTC)

Hi FrViPofm! Do you already know Proposed features/remove link to Wikidata from infoboxes ? --Chris2map (talk) 16:22, 1 March 2023 (UTC)

OK, the link was horrific. But this one :  ? A pity it has not been suggested better, cleverer use of this link, rather than only remove. Very often people on OSM think binarily : black/white, yes/no, indian/cowboy (I've been reverted for having corrected some obvious typos with taginfo-josm like building=hoouse because don't make mechanical edits but the rule seems more important than the reality : das haben wir nicht entschieden). Maybe it could be a link to the wikipedia page in the customer language that recorded in the wikidata page. I'm convinced it is possible in lua. It could be cleverer than a pure remove' solution. FrViPofm (talk) 09:26, 28 April 2023 (UTC) --moved from there; Chris2map (talk) 17:49, 6 June 2023 (UTC)

Some of problems discussed there are remaining, starting from "what is the realistic usefulness of this link and is it critical enough to include in a short summary of tag info". Also, many of this matches are not exactly proper matches (OSM tag definition and wikidata tag definition mismatch) and are misleading rather than useful Mateusz Konieczny (talk) 18:05, 6 June 2023 (UTC)

Exclude user pages from categorizing

Unresolved

We should exclude user pages from main categories. See an example here: User:Bubix/Sandbox1 - this userpage is in over 20 main categories. Not only userpages I mean here. We should limit categorization only to main namespaces. Main namespaces are:

• {{ns:0}} – (Main)
• {{ns:200}} – DE
• {{ns:202}} – FR
• {{ns:204}} – ES
• {{ns:206}} – IT
• {{ns:208}} – NL
• {{ns:210}} – RU
• {{ns:212}} – JA

For other namespaces, the categories should not show up. I only know how to build an expression for one namespace, I don't know how to do it for several without doing several nested ifs. An additional difficulty is that the content of this template is in several places like Template:DescriptionCategoriesLang and I don't know where this would need to be fixed. maro21 20:20, 8 May 2023 (UTC)

Largely done. See Template:Description and Module:DescriptionFromDataItem. --Chris2map (talk) 14:52, 9 June 2023 (UTC)

Yay! maro21 16:42, 9 June 2023 (UTC)

There are still some categories added by this template, see: User:Yurik/sandbox2. Also categories added by "group": example, and "Obsolete image file naming", "Unsupported status value". maro21 16:47, 9 June 2023 (UTC)

The first one (Yurik/sandbox2) used sandbox version of DescriptionFromDataItem - that is fixed now. – With the other cases, I thought they could slightly be more helpful than annoying. The group one for an overview what ist contributed to a topic. The latter ones for a full overview in preparation of a bot action. --Chris2map (talk) 17:50, 9 June 2023 (UTC)

I don't agree :). I think every main category should be excluded from userpages. Users write a draft version of an article before they move it to the main namespace, their userpages, sometimes ten years old, are in the main categories, so these categorization should be switched off by default. maro21 18:00, 4 July 2023 (UTC)

I added "debug" recognition to "group" categorization (if debug=<foo> is set in template) the page won't list in the group category according to the behavior with the other key and tag categories (see change). --Chris2map (talk) 16:56, 4 July 2023 (UTC)

More redirects

Resolved: Mateusz Konieczny (talk) 09:19, 26 June 2023 (UTC)

I propose to redirect Template talk:DescriptionLang and Template talk:DescriptionLang/doc/table Template talk:DescriptionLang/doc/table2 Template talk:DescriptionLang/doc/table3 Template talk:DescriptionLang/doc/table4 Template talk:DescriptionLang/doc/table5 Template talk:DescriptionLang/doc/table6 to this talk page to keep discussion in one place Mateusz Konieczny (talk) 05:50, 21 May 2023 (UTC)

Redirected Mateusz Konieczny (talk) 09:18, 26 June 2023 (UTC)

Wikidata remnants

Resolved: thanks!Mateusz Konieczny (talk) 09:20, 26 June 2023 (UTC)

How remnants of wikidata parameter can be removed from docs of page Template:DescriptionLang? I tried and failed Mateusz Konieczny (talk) 05:52, 21 May 2023 (UTC)

I purged the rest from Template:DescriptionLang/doc/table/row (diff), moved "Rendering" to table 5, so table 6 is empty now. --Chris2map (talk) 18:24, 21 May 2023 (UTC)

2x More details at taginfo

Resolved: Fixed. --Chris2map (talk) 09:32, 15 July 2023 (UTC)

If a tag doesn't appear in the OSM database, the template shows "More details at taginfo" twice. One is from {Taginfo2} template, but the other one is under the template. Compare: Tag:shop=solarium with Tag:leisure=tanning_salon. Why? maro21 19:12, 24 May 2023 (UTC)

I tip on the fallback link that is accidentally shown by taginfo2 / taginfoAJAX, apparently. I think ZeLonewolf would have to look at it. --Chris2map (talk) 20:09, 24 May 2023 (UTC)

I had previously planned to report this on the Taginfo2 template talk page, but when I pasted the examples, the link didn't show up. Now I see that the link does not show when the template is used more than once. Strange. maro21 20:39, 24 May 2023 (UTC)

I reported it there. maro21 20:50, 24 May 2023 (UTC)

Proposal to disable fallback display with applicabilities from tag key

Resolved: Fallback disabled. --Chris2map (talk) 09:32, 15 July 2023 (UTC)

This relates to the "Used on these elements" applicabilities of a tag: In following up Item talk:Q712 it is proposed not to use an automatic display of data from the key item of a tag in case there are no entries specified directly for the tag (tag value) itself. For now there is a fallback function activated in Module:DescriptionFromDataItem that takes the data from the corresponding tag key for applies to nodes, applies to ways, applies to areas and applies to relations if this data is not given with the tag. – However, in several cases this does not fit and can lead to inappropriate information. E.g. consider the tags with man_made=*. Some applies to ways, some to areas. So the applicabilities have to be set with the individual tags. Because this is not yet fully the case, especially in languages other than English, the fallback function leaves inaccurate information. – In order to prefer incomplete information to incorrect information, this fallback function should be disabled for the applicability informations of a tag. What is your opinion? --Chris2map (talk) 13:18, 24 June 2023 (UTC)

If you mean such change, I'm for it. maro21 14:23, 24 June 2023 (UTC)

That simple change is what I would do. -- Chris2map (talk) 15:56, 24 June 2023 (UTC)

Yes please! In my view, if after a week there is a majority in support, go for it. JesseFW (talk) 20:32, 24 June 2023 (UTC)

Makes sense to me, reducing such magic dependencies is a good idea Mateusz Konieczny (talk) 09:17, 26 June 2023 (UTC)

Change to module has been applied. --Chris2map (talk) 16:47, 4 July 2023 (UTC)

Infobox template

This template should be converted to use {{Infobox}} so that the wikitext is more readable and easier to modify without accidentally breaking page layouts. There's a lot of complex table code that got mucked up with {{!}} calls due to conditionals, but most of that can go away, because {{Infobox}} automatically hides any row whose |data# = parameter evaluates to an empty string. – Minh Nguyễn ^💬 02:11, 14 July 2023 (UTC)

I started drafting a User:Minh Nguyen/Template:Description based on the existing {{Description}} and {{Infobox}}. – Minh Nguyễn ^💬 08:23, 14 July 2023 (UTC)

Why "should"? And what do you mean by writing "the wikitext is more readable"? How can it be more readable? Could you give some examples of "accidentally breaking page layouts"? I use the Wiki a lot but I don't remember such cases. What is a conditional? Why do you want to change the design of the template, too, when you only write about the code? Why is it important for you? maro21 17:43, 14 July 2023 (UTC)

@Maro21: My intention is to streamline the underlying code inside Template:Description; I'm not currently interested in changing the visual design or the {{KeyDescription}} or {{ValueDescription}} parameters. User:Minh Nguyen/Template:Description does visually differ somewhat, but I consider it a work in progress. You can try it out by adding |basetemplate = User:Minh Nguyen/Template:Description to any transcluded {{KeyDescription}} or {{ValueDescription}} and previewing the page.

{{Infobox}} can help us get rid of a lot of messy, arcane, repetitive code like {{#if: {{{requires|}}} | <nowiki /> {{!}}- and {{#switch:{{{rtl|{{Dir|{{{lang|}}}}}}}}|rtl|yes=right|#default=left}}. This will help users avoid breaking the table syntax and surface subtle mistakes that last a long time without anyone noticing. I believe that anyone who has tried to make a nontrivial edit to {{Description}} will understand the need for this refactor.

This is important to me primarily because, as a technically-focused administrator here, I'm responsible for ensuring that high-traffic templates such as this one are well-maintained and perform well. Any change to this template massively floods the wiki's job queue, delaying rerenders of other pages throughout the site, so trial-and-error edits can be pretty disruptive. Moreover, this is one of the few remaining templates that still has the fingerprints of a user (since banned) who persistently used this wiki as a playground for their eccentric localization and programming ideas. We've been able to improve the wiki's functioning every time we chip away at that user's legacy here.

Do you have any concerns about how {{Infobox}} or Module:Infobox works? I can certainly try to address them while I'm in this area.

 – Minh Nguyễn ^💬 18:33, 14 July 2023 (UTC)

Thanks for the detailed answer. I'm fine with the change of the code if the appearance remains the same - I was a little scared by the new look because there were much smaller fonts. maro21 16:31, 16 July 2023 (UTC)

Nothing against a technical improvement, but I can't tell yet if that will make it easier or harder to continue our custom layout. I would also prefer the appearance to stay close to what we're used to (e.g. left-justified headers and text). One thing I can do without is the mini navbar. I would rather have a data item link for that, which is always there and on all language pages. --Chris2map (talk) 14:48, 17 July 2023 (UTC)

@Maro21 and Chris2map: Yes, the default styling can be overridden; I just haven't gotten around to it yet. On the other hand, if there are any visual tweaks you've always wanted but would've required invasive changes to the old code, this would help with that too. I did get rid of the mini navbar because it's next to useless. Anyone who would ever edit this template already knows where to find it. – Minh Nguyễn ^💬 17:21, 17 July 2023 (UTC)

Multiple values

Some keys allows multiple values separated by semi-colons, such as shop=* or opening_hours=*, some don't like access=*, but there is no way for data consumer to know unless querying taginfo. Could we add a field to describe this attribute in this template ? It would allow also to categorize automatically with Category:Uses semicolon in tag value and Category:No semicolon in tag value--Kioska Journo 11:55, 16 July 2023 (UTC)

Note that for shop=* semicolon listing is a bit dubious and opening_hours=* has entirely special own syntax Mateusz Konieczny (talk) 13:53, 16 July 2023 (UTC)

My bad, cuisine=* is a better example, but involuntarily this proved my point: using semi-colon for a value list is not something always obvious, it would be better to have a clear indicator.--Kioska Journo 14:12, 16 July 2023 (UTC)

No bad idea. If So I propose to add this information only on English pages and use a default no if it is not set, so that one has to set this parameter in case of multiple values only. --Chris2map (talk) 15:39, 16 July 2023 (UTC)

I think the information about whether values can be joined by semicolons should be included in the article. I, for example, in the article Key:beauty included such information. Keys that allow multiple values separated by semicolons are in the minority. maro21 16:37, 16 July 2023 (UTC)

@Maro21: I agree that the article is a better place for this nuanced information. shop=* is actually a good clarifying example: some data consumers like Mapbox Streets go out of their way to support multi-valued shop=* tags, just in case, but more would need to do so before anyone would feel comfortable tagging in that manner. The article can explain that situation better than an infobox row. Another important consideration is whether order matters and what the order means. For example, the order in ref=* matches the signs, the order in turn=* for a given lane is usually spatially ordered, and cuisine=* is anyone's guess. – Minh Nguyễn ^💬 17:57, 17 July 2023 (UTC)

Category checking status and statuslink

Resolved

It would be good to have a category that would collect pages of tags and keys in which "status=approved", but where the "statuslink" field is empty. Only pages in English.

Or not necessarily a category, but a script-generated list of such pages. maro21 14:50, 3 February 2024 (UTC)

@Maro21: Categorization added; is this what you have in mind? Category:Statuslink not set for approved tag; updating is still in progress and very slow – How is the naming to you? I wanted to start with the term "statuslink" for easy finding. --Chris2map (talk) 16:15, 4 February 2024 (UTC)

Wow, thanks for the quick response! I wonder if there will be a lot of such tags or keys. I've found such in the past, but mostly in non-English articles. Now the category has 17 pages. I wonder if that's all (I know categorization takes a long time and doesn't refresh in one day).

As for the name, I think the article is missing, shouldn't it be with "an" or "the"? But I'm not an English native speaker. I would give more in the plural: "Statuslink not set for approved tags". maro21 23:51, 4 February 2024 (UTC)

You're probably right! That's because I'm no English native, either. Same naming I chose for categories in Category:Missing data item in default namespace. An alternative might be "Category:Statuslink not given with status approved". – Count stays with 17. --Chris2map (talk) 19:12, 6 February 2024 (UTC)

Thanks for fixing those 17 pages. It seems that there were only 17, which is not a lot. I think it doesn't even make sense to create this category, because it's not as common mistake as I thought. maro21 19:28, 7 March 2024 (UTC)

Missing title above the taginfo-box

The infobox has a lot of titles like "Description" / "Rendering in OSM Carto" / "Group:" / "Used on these elements" / "Useful combination" / "Status:" / "Tools for this tag". The stats box of taginfo is directly below title "Status:". So i think there is a missing title like "Usage count:" or "Database stats:" or something else more suited which i propose hereby. --MalgiK (talk) 14:17, 6 February 2024 (UTC)

After reading your comment a few days ago, I initially thought the suggestion was unnecessary. But basically you are right. The numbers could also be viewed as part of the Status section, but formally a separate heading would be correct. However considering that another heading doesn't make the box any nicer, I'm currently leaning towards leaving it alone. --Chris2map (talk) 13:11, 3 March 2024 (UTC)

Your are right the numbers have some logical connection with the status. The numbers give some direction how the status value is set (especially for values like "de facto" and "in use"). "... another heading": From the situation now (1), i would not add another heading inside the box ({{Taginfo2}}) see (2), my proposal would look like (3): a new big title outside the box, and little format tunning (the taginfo-box moved a little bit to the right side).

--MalgiK (talk) 12:55, 5 March 2024 (UTC)

I think the taginfo box is so popular and people have seen it so many times that it is impossible to confuse it with something. And certainly not with status. Besides, the taginfo box itself is well explained - there are hints when you hover the mouse and you know what specific values mean. maro21 21:47, 4 March 2024 (UTC)

I don't think people are confused with the box, this is just to improve a bit the general structure (formating) of the info box. Yes it's well explained, even without the hover hints (i never noticed that ;-) ). :: --MalgiK (talk) 12:55, 5 March 2024 (UTC)

If then I would leave the ":" colon away like with the other multiline sections. Otherwise some might search for the count value behind the colon (like with "Documented values:" or "Status:"). --Chris2map (talk) 16:05, 5 March 2024 (UTC)

project parameter

Minh Nguyen, your change creates a redundant category Category:Not copied project. maro21 20:00, 27 August 2024 (UTC)

@Maro21: It isn't really redundant – the template does that automatically to indicate that the parameter isn't reflected in the associated data item. See the discussion at Item talk:Q10#OpenHistoricalMap concept. – Minh Nguyễn ^💬 01:33, 28 August 2024 (UTC)

Not all infobox parameters have a counterpart in data items, only a few. So I still think it's a bug, among other things, because it's currently impossible to delete this category. "project" is certainly not a parameter that can be copied, because it's technically impossible. maro21 16:21, 28 August 2024 (UTC)