Template talk:Description

From OpenStreetMap Wiki
Jump to navigation Jump to search


Language-specific tool links

Hi, let me first say thank you for the amount of work all this must have been. I think that the consolidation of the various versions of this template is a step in the right direction. Unfortunately, I'm having a hard time following the MediaWiki template syntax across the many templates despite your laudable effort to include comments. So could you perhaps help me understand how having different tool links for each language will work? --Tordanik 16:50, 31 March 2014 (UTC)

Thanks. :-) I really think this could make a difference. Yes, when I started, I thought that per-language support for external links would be a sensible thing. But when I analysed which external links the various templates provided, there was some language-based variation, but almost exclusively to sites which no longer functioned. Here's an analysis of which sites are linked to across the entire set of templates:
Website occurrences site status
http://tagwatch.stoecker.eu/ 356 redirects to taginfo.openstreetmap.org
http://tagstat.hypercube.telascience.org/ 32 site no longer active
http://overpass-turbo.eu/ 15 active site
http://taginfo.openstreetmap.us/ 6 active site, but data almost a year old
http://taginfo.openstreetmap.org.uk/ 5 active site with recent data
http://taginfo.openstreetmap.fr/ 5 active site with recent data
http://taginfo.hanskalabs.net/ 5 server error
http://taginfo.openstreetmap.org/ 3 active site with recent data
http://osmdoc.com/ 3 domain parked
http://taginfo.openstreetmap.cz/ 2 active site
http://www.google.com/ 1 well, it's Google
So, that left only three or four active sites, and I managed to squeeze them quite happily into the bottom of the box, via the {{DescriptionLinks}} template, which I seem to have missed in the tree above - sorry, I'll fix that. The template is passed the language of the description box, so it could, as was originally the idea, provide links which are specific to that language/locale. But it's not at the moment, as there aren't any to provide… If/when there's call for it, I (or someone else) can add this in, but at the moment everyone gets the same external links. For now, that's probably quite a good thing, perhaps. Moresby (talk) 22:13, 31 March 2014 (UTC)
The obvious canditates would be the local taginfo instances. Right now it's just UK/US/FR for everyone, but the several sites on openstreetmap.ru seem pretty much alive, It's not something that has to be done right now, of course. But it's good to know that we will be able to provide a bit more variation eventually. --Tordanik 23:24, 31 March 2014 (UTC)
OK, breaking news: have a look here. Each user can now configure which country sites he/she wants in addition or instead of the default set. I'm working on being able to set a different default set for descriptions of a given language, but that's not there yet. Do let me know what you think.... Moresby (talk) 13:26, 12 April 2014 (UTC)
Done now. Each language has its own set of taginfo links. I've made a stab at putting the mapping together here but I'm sure it could do with specialist knowledge. Moresby (talk) 16:31, 12 April 2014 (UTC)
Resolved: Seems to be solved and/or outdated Mateusz Konieczny (talk) 11:31, 25 January 2021 (UTC)


Website and URL pattern

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

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

Formatting of parameters

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


Templates without image parameter

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

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

Wikidata

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


Wikidata link

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

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

One discussion place

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

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

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)

Categorization and capitalization of group

I started a discussion about categorization and capitalization of group here: Category talk:Tag descriptions by group

I believe that this template should convert the capitalization of group to Group for categories it creates as it is displayed and used in this way for a long time. An alternative could be to change it to group from now on. But we should choose one way and do not allow a mixture of Group and group. Chrabros (talk) 05:19, 12 March 2017 (UTC)

It has started with low<ercase almost everywhere, except in placers where there were unexpected duplication. For now it is indepenant of how if is displayed in the box (using generated capitals), but there's no way to reverse the capitalization for maing categories. For now these categories by group are still experimental, but not widely disployed (Tag descriptions for group "<groupname>") when in fact I think it should just be "<Groupname>" in most cases. Note that when both are existing, tag description pages will be categorized in both. Nothing happens for sorting pages by group if neither one of these two subcats have been first created (this still works as an experimentation but groups (and subgroups) is still not very well organized and experimetnation continues with them. We are not required to set groups for every tag description page or every key page, they only exist where there's some reasonnable reason for grouping several related topics. — Verdy_p (talk) 22:17, 12 March 2017 (UTC)
I would like to clearly state that I would like to use the categories by group and I can not because Verdy_p insists on having the categories' names in lowercase but users enter the group= parameter almost consistently in TagDescription and KeyDescription with first capital letter. The result is that we have many categories pre-created with names in lower case but with no contents. I would like to fix that. Please someone choose either Group or group and automatically convert the case of created groups in this template. Thank you vey much in advance. Chrabros (talk) 00:24, 13 March 2017 (UTC)
You are only wanting to make an unilateral change that would affect MANY MANY pages that have been created with these lowercase letters (not jsut by me but long before, when groups where first introduced.
Once again you don't understand that your change will require much more work. The few pages that used capitals there were created as errors, creating a few duplicate categories.
And writing parameter values from the group name with their normal orthography, is absolutely NOT blocking you to use these groups! Many groupos already exist since long and are filled this way.
This does not change the fact that the pages in questions have consistently used since the begining the initial NOT uppercased, even if the infobox just displays them with a leading capital.
This also does not affect how categories where the group name is used in isolation are still using a leading capital (like all other categories or pages, not just group).
Really look at these existing categories (note that categories by group are not used for all tag or description pages, and there's a lot more work to do; but all the important groups used by the most frequent tags have used lowercase group names in their categories since ever (notably because this was frequently the same lowercase value used in OSM tag keys or in OSM tag values) !
You are only confused by what the infobox displays on description pages themselves: the capitalization of the parameter is made only there.
And if you think it is simple, you seem to ignore the requirements of different languages (those written in bicameral scripts) about capitalisation (notably English, French, German and Georgian have very different rules).
Note: the categories in Category:Key descriptions by group are much more populated for now than those in Category:Tag descriptions by group (they use the same naming scheme).
Verdy_p (talk) 05:43, 13 March 2017 (UTC)
Note also that this is documented since long this way in templates generating the infoboxes. Read the doc ! You were not there 3 years ago (first by Moresby) when all this started to be implemented and a cleanup project started that decided all this trying to unify many more inconsistant naming schemes. Groups were then added and tested, then started to be used slowly, but consistently (until recently) when these categories started being used (and the first ones created were using the same value as important key names (lowercased). — Verdy_p (talk) 06:02, 13 March 2017 (UTC)
Final note: it's much simpler to edit tag description pages than changing names of categories. Only a small fraction of all tag pages or key page names still use this parameter. But everything was documented with examples. — Verdy_p (talk) 06:10, 13 March 2017 (UTC)
Where in the documentation of {{Description}} stands that group name should be case sensitive? I cannot find it. Chrabros (talk) 09:40, 13 March 2017 (UTC)
PS: Yes, I was here when this change of templates was implemented. Chrabros (talk) 09:42, 13 March 2017 (UTC)
So I did my little math. There are 12244 tag/key pages, out of them 5055 has a group filled in. And quess what 895 of them start with lower case letter and 4109 start with upper case.
So you are suggesting that we fix 4109 pages, instead of few categories, because you do not want to acknowledge that you have made a mistake when initially creating it. Nice. Chrabros (talk) 11:10, 13 March 2017 (UTC)
I don't lie, read the example above which was the inital one. The later example was added much later, without checking the result, and it was wrong for this issue. Since the begining the categories have all been created with lowercase (and not by me), and used as documented since the start. I participanted to the initial template but did not choose and did not change the naming convention that was already there.
Please don't select only one thing in pages without loosing the hitory and ignoring the rest of the page. And don't use harassing abusing words like you did here again. — Verdy_p (talk) 12:51, 13 March 2017 (UTC)
OK. Let's just say that changing the documentation during a discussion about it is not nice.
But there is the documentation you are constantly refering to? This one example of group=shop and the second with group=Historic?
As I can see the second example was added on 18. 4. 2014 by Moresby himself. This is same day this template was rolled out. Again dubious information given by you.
Anyway I have not found any documentation stating that the group parameter ought to be case sensitive and that for those categories it is required to be lower case. Where is it?
And the most important question: How do you propose to amend this situation?
Chrabros (talk) 13:57, 13 March 2017 (UTC)
The documentation was correct and not changed, the first examples given were correct and not changed, only the last example added later was incoherent.
The code was not changed to force a change of lettercase (this will be even worse than fixing pages (it's much more complicate to change the category naming as it requires editing them multiple times, as well as editing all member pages as well. — Verdy_p (talk) 14:58, 14 March 2017 (UTC)
OK I read your answer like this: It was never documented anywhere that the categories are case sensistive and that we want them lowercase in English, except for this one example.
So what do you propose to do now to populate the categories? Chrabros (talk) 02:04, 15 March 2017 (UTC)
If you look at all these categoies, they are already using lowercase since long, using group names but not in isolation. When groups where first introduced there were several schemes proposed, and unification with several tests was still not tested. But then it became possible to use BOTH categories with group names used in isolation (i.e. Category:group) for common topics (many of them already existing, but where the initial is normally not case sensitive except after a language name prefix, so for this case only the initial is forced to uppercase to allow interlingual navigation), and as part of the name (i.e. Category:Tag description for group "group" or Category:Key description for group "group") where case is always significant (so forcing case is not enforced there).
Still when this was created 3 years ago, groups were still experimental, then more or less well added to Key/Tag pages without seeing what was their effect (notably because this was still experimental, pages were added to these categories ONLY if these categories were existing). Nobody noticed, when they added groups, that one of the two categories (named in isolation, or in a longer name) was fed. The initial tests were ONLY using lowercase.
The error came later because many pages were modified to add group names without seeing if it had the intended effect: all these edits were wrong. But it's simple to fix them (even if there are about 5000 Tag/Key pages, it does not require extensive edits, and it's much simpler than having to recreate thousands of categories, plus editing all member pages, and creating the redirecting categories for navigation; and not all languages are concerned by these changes, notably there's no need to edit the Japanese pages that already use translated group names, but with category redirects for their matchiung category in English: here again we should avoid having to handle thousands of new category redirects, notably now that updates in categories or changes of categories in pages are extremely slow since the recent upgrade of MediaWiki version on this server: the job queue has been slowed down dramatically).
We are reaching a point where the initial experimention on using groups starts being wanted. We can fix the 5000 pages created without testing them. It won't affect the navigation, and no new categoy redirects are needed.
Not also that not all languages are using categoies by group: this is disabled by default, and only enabled in a few languages where category names have been tuned.
I still maintain that the intent since the begining was to have group names in English being lowercase, just to match also the key names or value names used in OSM tags. But group names are still translatable: they are not necessarily in British English. We won't change how OSM tags are named themselves, and external tools depending on them to find their doc will remain as is.
Groups are completely underdeveloped, and still need structuration (there are cases where duplicate group names also exist with singular or plural in English, when other languages do not have such distinction, notably Asian languages). Ideally some tags could belong simultanesouly to several groups (but for now only one is supported: other groups are only added by adding categories in pages themselves, or adding links in descriptions).
Forcing existing pages in the description templates to force lowercase will have impact. We could do that, but with a test that will detect when this changes the effective full page names we want to link to: I would suggest just adding a tracking category and then look at it to see what is detected. It will take lot of time to be reflected. But at least we will be able to cleanup the situation progressively without having to make massive changes without measuring their effect and having the possibility to revert them. I don't like the idea of using "lcfirst:" it does not work correctly in various languages (and notably not in German). Only "ucfirst:" is safe, provided this is the initial word in page names (and here it is not the case).
Then you say "it was not documented", well it was documented indirectly in the first correct example (with group=shop) but incorrect in the last example (with group=Historic). About the "historic" group it is already fixed. the example is also fixed. So there only remains the Key/Tag pages added later that have used incorrect values (with noone detecting it, not even those that added these groups without reviewing them).
I suggest then to just detect in *English-only* Tag/Key pags names using the template with a group name with an initial capital (where lcfirst:group and group will be different) and track these pages in a maintenance category. But not changing the categories that will be looked for. A single tracking category will be enough. Then their translated pages will just have to update the same fixed group name as English (if needed: not needed in Japanese for example where almost all group names are already translated). A few new categories were added recently for Spanish using the same capitalization as English, but there's not a lot of them). — Verdy_p (talk) 03:32, 15 March 2017 (UTC)
I still don't understand where this recreate thousands of categories comes from. Thousands? I see 8 categories in Category:Tag descriptions by group (not counting Japanese as I doubt they have capital letters) and 71 categories Category:Key descriptions by group. It is not that complicated. Chrabros (talk) 05:07, 15 March 2017 (UTC)
You forget Category:Key descriptions by group also impacted and their translations and their redirects when translated (including redirects for Japanese). Well it's not thousands, but still complicate.
There's no emergency to create new groups, there's other cleanup to do first (including merging duplicates and making sure that groups are correctly organized), for now most groups have just been randomly created without thinking about what would fit in them. We can cleanup this. But even before the (still experimental groups) there's priority for other tasks listed since long in this page. Groups were unfoirtunately added when basic cleanup listed above was still far from being finished. For now these groups are accessory and work only for a few ones where there are related contents also outside Tag/Key pages. — Verdy_p (talk) 14:06, 15 March 2017 (UTC)
As we cannot reach any consensus I have summarized the problem and its solution from my point of view and called for others to state their opinions. Hopefully we can settle on something. The proposal is here: Talk:Wiki#Proposal_for_creating_group_categories. Thanks. Chrabros (talk) 04:28, 16 March 2017 (UTC)
Well, it seems that no one has shown any interest in this problem for a week which I find little bit sad.
As we are not able to reach any consensus about group naming in English I think nothing will happen for some time. However there is a consensus for Czech naming of groups. We would like to have them with first letter auto capitalized. Are you able and willing to implement this change for us? You have definitely more experience with those templates than I do. I am affraid that if I will try to do it it would be painful for me and for the wiki as well. Thanks. Chrabros (talk) 23:03, 21 March 2017 (UTC)
(Unindenting below).Verdy_p (talk) 00:00, 22 March 2017 (UTC)
Of course I can supply this capitalization for Czech if this is the consensus. But you'll have to change various categories (note thaty editing tag/key pagers for changing the capitalisation of status=* values has no effect, as these values are only specified in English and the letter case of these English values is always ignored to find categories and translate what is displayed in the navbox, or the name of translated categories; the actual capitalization being part of the templates performing the translations: it is quite easy to do for these status values, that are fully enumerated, but not so evident for groups that form an always growing and open set that will need to evolve over time).
As you request it for Czech, I could do that only for Czech (but not for English) and the problem is that you xanted that for English too and have even needlessly started to change case in English group names without looking at the many existing categories that depended on lettercase and need to have translated categories linked together from the same English base name for the {{Languages|Category:name of relevant category for "groupname"}}. It's not simpel to change English without a larger consensus and lot of work. But as groups are still very unstructured and more or less "flat" (and will very likely changed in many Tag/Key pages to structure them and associate them to existing relevant features), I think it's still overkill to change these names for now.
Note that ll your Czech categories are already using lowercase (using untranslated group names!):
Do you see the problem? Groups are still in very alphas stage, not fully setup in English, so their translation is still extremely optional. We should not have to maintain categories fro names that are missing also in lot of places or were not coherently chosen (and it's not jus a question of capitalization, but more importanyly a problem of relevance for terms).
You'll also see that when pages are categorized in Category:Cs:Popisy klíčů skupiny "historic", they should no longer be categorized in Category:Historic or its translations, but the relations between the two are still not established, and it was still enver decided to make such moves, because groups are still very experimental. In other cases, groups only exist in isolation and in most languages there's no such category similar to Category:Cs:Popisy klíčů skupiny "historic", because precisely tags/keys per groups are disabled by default but they are categorized directly in Category:Historic or its translations.
Given the huge cost in maintenance of categories, I think it is strill much simpler to maintain only separate pages that will populate only a few categories that have been requested and not disabled by the current default naming scheme. Just write them in lowercase in group=* parameters of navboxes (like for status=*) and there's nothing more to do. — Verdy_p (talk) 23:58, 21 March 2017 (UTC)
Yes, we need some consensus. But it seems that no one else cares. So please try to auto-capitalize the category name for those Czech groups and I will rename then those two existing categories to Category:Cs:Popisy klíčů skupiny "Historic" and Category:Cs:Popisy klíčů skupiny "Tourism". Thanks. Chrabros (talk) 01:04, 22 March 2017 (UTC)
Well, I have renamed the categories, but the tags and keys still point to the old lower case ones. With the exception of tags/keys I have edited afterwards. Do you know if there is some robot which would re-categorize all those tags/keys in the background some day? Or it it categorizes only while saving som changes? Chrabros (talk) 23:58, 22 March 2017 (UTC)
OK, while examining it further it seems that there is some bot, because some keys were re-categorized without editing. However it is very strange if you have a look at

The keys with group=properties stays in the "properties" group while those with group=Properties were moved into the "Properties" group. Do you know why? Or is it just coincidence? Thanks. Chrabros (talk) 00:16, 23 March 2017 (UTC)

As I said you will still need to reference the unchanged English name for categories. I have not changed the English categories at all (and not any other languageà. So keep lowercase in the parameter for the Languages template used in the Czech categories. I had warned you multiple times about that : all other languages are still linking the Czech pages from the unchanged English category name! — Verdy_p (talk) 00:34, 23 March 2017 (UTC)
Note: there's NO bot running. But categories are indexed by background jobs (and we depend on the speed of the job queue handler, which is much slower now compared to before the recent upgrade of MediaWiki. So there are delays to see any page being visible in the new category when a page (or transcluded templates) are modified. Even performing a null-edit (edit/save without change) no longer accelerate the reindexing job if the page is already queued. You will need to wait until the job queue advances: the change being already queued, it will happen but withoiut any guaranteed delay. See statistics about job queue with the MediaWiki API (because it's no longer visible in the Special:Statistics page since long!) You'll find an API link in the Servers status page (linked from the home page): it gives the current job queue length in a JSON, just formatted for HTML when viewing it from a browser. Note that sometimes the job queu can be extremely long and will stall, constantly growing for days (sometimes several weeks...) if a job is extremely expensive (this happens notably after any MediaWiki verrsion upgrade on the server when it is busy recreating new indexes: this wiki server is much less powerfull than Wikipedia or Commons where the job queue is operated by multiple concurrent servers and with a high level of parallelism of database servers. This wiki does not run in a large farm with many servers like in Wikimedia. — Verdy_p (talk) 00:44, 23 March 2017 (UTC)
Why should I keep lowercase group in the Czech template Description? I do not understand it. There should be no relation to English categories in Czech tag/key description page. Or is it? Where?
Anyway it seems to work for recently edited pages with both group=Náboženství and group=náboženství. See here: Category:Cs:Popisy značek skupiny "Náboženství".
So I do not understand why you instist that I should use group= with lower case in Czech pages. It should be autocapitalized now. Chrabros (talk) 01:05, 23 March 2017 (UTC)
I only inist for now on keeping thing unchanged on English for now, because it affects all languages, and because, as you've seen, changes in category names are not immediately visible and renaming them is not so easy (and anyway these categories are still experimental and were not seriously discussed and structured correctly, they are enabled only in a few languages and disabled by default in all others). — Verdy_p (talk) 13:00, 23 March 2017 (UTC)
@Chrabros: do you still think that it should be changed? Mateusz Konieczny (talk) 11:35, 25 January 2021 (UTC)

openstreetmap-carto rendering: unknown versus not rendered

Can a distinction be made in this template such that a categorical distinction exists between, say:

osmcarto-rendering = versus osmcarto-rendering = NotRendered?

In the case where a value is explicitly not rendered by openstreetmap-carto, there should be able to be an indication of that by template, so that what appears under rendering is something like not rendered by osm-carto (or its translated equivalent for whatever language template it is), rather than a blank space.

Doing this provides information that is lacking, particularly when the use of taglists transclusion and its with_rendering option is brought into play, since there is no mechanism to do that there.

This would provide valuable information:

  • The default for (blank) can be something like a '?' svg, meaning 'unknown', and someone should vet how it's rendered (or if it is at all, going back to 'NotRendered' or similar)
  • When Feature elements are transcluded via taglists and with_rendering, a distinction is made in those tables as well

Skybunny (talk) 02:37, 18 September 2017 (UTC)

Rendering can appear at any time, if ther's no rendering for now it jsut means that there's currently no support and usage or presence in data (and support for QA tools) has still not been developed enough to render it, or simply no one proposed a suitable icon for the POI. So the "status" (and tags statistics) should be a hint about which feature will next be rendered. We cannot render everything on maps, and there are even variants that will appear first for specific renderers tuned for some regions. I don't think its relevant to add anything for something that is currently not rendered. Categories are also not needed (beside the status categories). — Verdy_p (talk) 10:41, 18 September 2017 (UTC)


Resolved: In this case Verdy_p makes good point that was not answered for over 3 years Mateusz Konieczny (talk) 11:35, 25 January 2021 (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)

Add alt-text for small images?

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:17, 4 August 2019 (UTC)

I wholeheartedly agree that there should be alt text for these images, but ... isn't that already the case? Here's some snippets from the HTML of Key:highway:
<img alt="Edit or translate this description." src="https://upload.wikimedia.org/wikipedia/commons/thumb/6/63/Arbcom_ru_editing.svg/12px-Arbcom_ru_editing.svg.png"
<a href="/wiki/Node" title="may be used on nodes"><img alt="may be used on nodes" src="/w/images/thumb/7/76/Osm_element_node.svg/30px-Osm_element_node.svg.png" width="30" height="30"
--Tordanik 19:53, 9 August 2019 (UTC)
Ugh, you are right, it's a problem / feature of my browser: the alt text is only displayed as hoverover / mouseover text in Safari after waiting a few seconds, even when images are not loaded. I should try Opera. --Jeisenbe (talk) 06:45, 10 August 2019 (UTC)
Resolved: Mateusz Konieczny (talk) 11:36, 25 January 2021 (UTC)


Recent addition of rendering samples

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

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


Remove wikidata from this template

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

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

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

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

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

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

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


Language Question about v * d * e

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

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


Proposal to merge part of documentation

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

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

Merge discussions

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

Misleading tooltip (alt text) for relation

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

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

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

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

Obviously both negated and not negated versions should be changed.

Where it is defined?

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

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