Template talk:ValueDescription

From OpenStreetMap Wiki
Jump to navigation Jump to search

This template is used to get a well designed structure into the available tags that exist to describe a map feature.

There is no need to change the template itself if you just want to create a new Tag:somekey=whatever page or translate a existing page into your language!
Please read the template documentation to get a clue about how to use this template.

Translating a existing page

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

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

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

Changes

Okay, so as you might have seen, I've been making a few minor changes to the template. Mostly so far just the addition of a onRelation= tag, and a few changes so that some fields don't get displayed if the variable isn't declared. For instance, if you use image= you get the 'No image yet' image as before, but if you don't include the image= parameter at all, then no image is included. This is useful where having an image wouldn't really add much to people's understanding of the key-value, and so displaying 'no image yet' isn't that helpful.

Other changes I think might be useful, but which I haven't implemented yet, are:

  • include some of the tagwatch count data directly in the infobox itself (would have to be updated occasionally though).
  • remove the link to Wikipedia 'definition', or at least make this optional. I find that it doesn't really add much in most cases, and we should be 'defining'/describing the tag on the page itself.
  • remove link to 'user discussion'. There's already a tab for this!
  • find some way of minimising all the links to tagwatch. these are very useful, but take up a lot of the box.
  • adding images of how the tag is rendered in some of the popular map styles (Mapnik/Osmarender/cycle maps/etc).
  • rename 'Useful combination' as 'Often used in combination with' (or similar).
  • Make the node/way/area tags link to pages describing those elements, rather than their image pages (really need the Icon extension to do this easily).

Any thoughts/objections?

Frankie Roberto 20:57, 22 February 2009 (UTC)

I agree with removing definition and especially discussion links. The definitions aren't necessarily helpful -- the relevant definition is the one given by the page itself, not by some external sources. If external links (e.g. to Wikipedia) are useful, they are commonly provided anyway (using the [[wikipedia:foo]] syntax). Using the icons as links to element pages is probably a good idea, too.
I don't agree wih including tagwatch information in the box, especially if it would require page updates to keep the info up to date. You couldn't put all the information from tagwatch in that box anyway, and a single click really isn't too much effort.
I also don't agree with "Often used in combination with", because I believe that this section shouldn't simply be based on usage statistics (again, we have Tagwatch for that), but on the page authors' human intelligence.
Btw, could you please apply the changes you made so far to Template:KeyDescription, too? --Tordanik 11:56, 23 February 2009 (UTC)

Wikidata

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

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

[Outdent]

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

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

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

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

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

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

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

Categorisation Change

I changed

<includeonly>[[Category:{{{lang|en}}}:Tags|{{{key}}}]][[Category:Tags_by_value|{{{value}}}]] {{#if: {{{image|}}} ||[[Category:Feature pages with missing images]]}}</includeonly>

to

<includeonly>{{#ifeq: {{lc:{{#ifeq: {{{lang|en}}}|en||{{{lang}}}:}}Tag:{{{key}}}.3D{{{value}}}}} | {{lc:{{anchorencode:{{FULLPAGENAME}}}}}} |[[Category:{{{lang|en}}}:Tags|{{{key}}}]][[Category:{{{lang|en}}}:Tags_by_value|{{{value}}}]]|}}{{#if: {{{image|}}} ||[[Category:Feature pages with missing images]]}}</includeonly>

to only categorise pages with names in the format (lang:)Tag:(key)=(value) in the first two categories. I didn't change the bit about the image. This change was also added to the De, Fi and Pt versions of this page to keep categorisation consistent. The template was also being used in Proposed Features pages which didn't really seem to fit the category properly. The .3D and the anchorencode: were to handle spaces in page names where there were underscores in keys or values. It also then categorised the tags_by_value by language as was already the case with the tags category. --EdLoach 23:40, 25 June 2009 (UTC)

So it appears that the auto-categorization remains non-functional, correct? My apologies, I was looking at implementation on the improperly named page Key:access:bdouble; this function works after moving the page to Tag:access=bdouble. --Ceyockey 14:34, 11 November 2010 (UTC)

seeAlso Change

Added See also section for seeAlso parameter. See Tag:boundary=administrative for an implementation. FrViPofm 11:19, 21 September 2009 (UTC)

It works OK on that example, although it's maybe duplicating what should be on the page itself. Indeed Tag:boundary=administrative does have a "See Also" heading at the bottom of the page which has more things listed, so... well is it a bit weird to have two different "see also's" ? Should the "seeAlso" param be a summary/prioritised item from the larger list on the main page content?
So you get this duplication. Or the other thing which happens is, we get "see also" info which is not in the page content. e.g. Currently on the Tag:sport=table_tennis. Easily fixed I suppose.
Another thing is, I usually find "See also" heading is better renamed as the more descriptive headings "Similar tags", and "Tags to use in combination". See also is kind of a lazy heading, used when people can't be bothered to think of a better way to add a link (not that I don't do it myself, but I think it's good to avoid)
-- Harry Wood (talk) 11:00, 1 August 2014 (UTC)

Template:Lang:ValueDescription

We have some many translated templates but we can't switch between "Lang". Why?--Władysław Komorek 22:16, 25 September 2012 (BST) "Available languages" bar doesn't work for this template.--Władysław Komorek 22:19, 25 September 2012 (BST)

lang=de (and all others, too?) still does not work! --miloscia 18:27, 11 August 2013 (UTC)
That's unsurprising because, although the parameter is documented, there is no translation mechanism in this template (except some code in the automatically embedded Languages bar). Pages typically use templates such as Template:DE:ValueDescription. --Tordanik 10:21, 12 August 2013 (UTC)
Then there are 2 possibilities: Either, the "lang" parameter is removed from the documentation page and instad, the user is told to use the referred language templates. Or this template is changed in order to enable a language switch (which should not be too difficult using the "switch" function). What is preferred? --miloscia 13:40, 12 August 2013 (UTC)

I'd prefer the latter possibility. My test (see recent changes) using a 'switch' in Template:ValueDescriptionLang is working :). Other languages can easily be added. Is it okay? miloscia 10:32, 15 August 2013 (UTC)

better to make one offer universal analog template for any other templates such as KeyDescription, ValueDescription and other --dr&mx (talk) 18:46, 15 August 2013 (UTC)
I'm sorry, I do not really understand your comment. I moved the "translation template" to Template:DescriptionLang, and of course it can be used in Template:KeyDescription as well. --miloscia 12:19, 16 August 2013 (UTC)
The "tagstat" or "tools for this tag" seems a little different in each language template. Using one single template structure makes it easier to manage that, i.e., make it comparable for all languages. In the long run, all templates like Template:DE:ValueDescription can be deleted. miloscia 12:43, 16 August 2013 (UTC)
Could you give a reason why you prefer that possibility? Although I think it would be acceptable, it should be noted that currently most of the Tag:* pages use the first option (i.e. separate templates for each language), so my default reaction would be to stick with it unless there are good reasons to switch. It's also not just a simple matter of translation because the content is somewhat different, and at least in some cases that is intentional. For example, the German version has tool links for Germany, Austria and Switzerland (the largest German-speaking countries), whereas the English one has continent-wide statistics due to its global role. --Tordanik 12:50, 16 August 2013 (UTC)
Well, to me it just seemed that possibility is easier and more clear and thus changes can be implemented directly, whereas now you have to compare each language template, which is a little different. Therefore, language templates which were created by copy&paste (and translating a few words) seemed "unnecessary" for me - Keep it short and simple.
I'm rather new here, but I've been working in several Wikimedia projects (which is why I'm familiar to the template structures and programming). Having the tool links in mind, separare templates would - of course - be acceptable for me, too - if maintained consequently. (However, using a "switch" for the tool sections suitable for the corresponding country would be possible aswell.) --miloscia 07:22, 17 August 2013 (UTC)
You can program Mediawiki within the template so that it displays statistics for a different selection of countries as easily as you can display messages in different languages. The existence of the #switch statement is a clear sign that the different links are intentional (for instance someone might simply copy and paste updated tool URLs in cases of linkrot without even noticing the difference) and oddities such as the second language box in Template:DE:RelationDescription can be justified or removed. Andrew (talk) 14:14, 18 August 2013 (UTC)

Revert of new images

I've reverted the replacement of the element type images with new counterparts. The primary reason is the unsuitable license: Icons used here need to be in the public domain because clicking the icon does not show the image description page. Therefore, the attribution requirement of CC-BY or CC-BY-SA could not be fulfilled. But there's also the question what the point replacing some icons with almost identical versions was in the first place: Mf node yes.svg Osm element node.svg --Tordanik 17:04, 15 March 2014 (UTC)

Resolved: I think that this one may be archived Mateusz Konieczny (talk) 10:27, 16 April 2019 (UTC)

Closed way icon

Hidden amidst of some visual embellishments without changeset comments, a "closed way" element icon was added to the infobox. Closed ways generally don't have special semantics afaik, so is there a need to emphasize them in tagging documentation? I would be interested in hearing the reasoning for that change. --Tordanik 21:37, 15 March 2014 (UTC)

Good question. There are some tags which are applied overwhelmingly to closed ways, rather than open ways (<0.1% of ways tagged with building=* in the UK are open), some which are applied overwhelmingly to open ways, rather than closed ways (<1% of ways tagged highway=* in the UK are closed) and some which are much more balanced (a little over half of ways tagged access=* in the UK are open ways). There are complex subtleties in the differences between ways, closed ways, and areas, in particular associated with how they are rendered. I am trying to make some of these distinctions clearer, and document the way in which tags have a role in this. It's going to take a while to get there, but it should make certain things clearer, and make it easier to spot tagging mistakes. Moresby (talk) 23:03, 15 March 2014 (UTC)
I do not oppose the ClosedWay as such but I would welcome if Moresby could explain some changes on appropriate talk pages and also in comments while editing pages. I think that it is nice to have onClosedWay and onArea. It is a step toward making it clear. Chrabros (talk) 01:19, 16 March 2014 (UTC)
That's a fair point - I'm sorry I haven't been clearer. I've recently done a lot of work on a wiki where people are not interested in discussing changes at all, and edit comments are seldom used. It's something of a culture change to get back to somewhere where people are actually using these mechanisms, and I think I need to readjust. :-) Moresby (talk) 08:29, 16 March 2014 (UTC)
In the examples given so far, the closed way icon isn't actually helpful. Buildings are areas, not rings, and in fact the only case where closed ways have special semantics is when they are used to model areas. --Tordanik 13:45, 16 March 2014 (UTC)
Moresby? I've noticed that you continue to insert onClosedWay options to other language versions of this template. Could we please finish this discussion first? --Tordanik 09:27, 17 March 2014 (UTC)
Yes, you're right. I've addressed the points you've made, nobody else seems to have a problem, and Chrabros has described this as a "nice to have", while pointing out some things to address, which I have picked up on. In going through, looking at other language support, I've identified and fixed several problems, and am making other language templates more up-to-date and consistent with the English ones. From the looks of things, native speakers of other languages aren't faring that well, compared to English, and I want to do what I can to make them appear less like second-class citizens. Moresby (talk) 10:12, 17 March 2014 (UTC)
Ah, just seen your comments about ways versus areas. That's a good point. Actually, there is a distinction between closed ways and areas as to how they are rendered. A closed way which is a highway is rendered as a "circular" road, whereas a closed way which is landuse is treated as an area. This is quite a subtle distinction to make, which is why it needs more time and clarity, and the different effects which tags have need to be made clearer to people who don't want to delve into the renderer source code. This source file is quite interesting as to how the distinctions happen, as is the way in which osm2pgsql imports data. Once things are little more easy to see, it becomes a lot clearer what area=yes is for, and when it is appropriate, for example. Moresby (talk) 10:41, 17 March 2014 (UTC)
The information whether a closed way is considered an area by default or only with area=yes would be useful in some cases. If you have an idea how to make that more clear, I'm open to suggestions. I still maintain that the information "this can be used on closed ways" is not useful, because this is semantically not different from two non-closed ways forming a closed loop. So we would just end up repeating onWay. --Tordanik 15:40, 17 March 2014 (UTC)
I thought that onClosedWay means that when it is used on a closed way it remains a way not area. Similar to onArea - when it is used on a closed way it becomes an area. But probably I am missing something here in this discussion. Chrabros (talk) 04:42, 18 March 2014 (UTC)
IMHO The best example for ClosedWay is the boundary of the city or fence. --Władysław Komorek (talk) 07:38, 18 March 2014 (UTC)
Do you mean ways that form part of the edge of an area? --Andrew (talk) 21:20, 18 March 2014 (UTC)
Yes. Without area=yes. --Władysław Komorek (talk) 21:47, 18 March 2014 (UTC)
Nobody questions that closed ways exist, the question is whether onClosedWay adds any value. In my opinion, onWay=yes automatically means onClosedWay=yes. If a way tag doesn't make sense on a closed ways, it's because such a thing doesn't exist in reality, it has nothing to do with the data model. --Tordanik 16:42, 22 March 2014 (UTC)
In my opinion this new closed way icon doesn't make much sense. Now has every value page a question mark button, which is not really necessary. I propose to remove onClosedWay from the template again. --Andi 21:37, 26 March 2014 (UTC)
If you really must, go ahead. I've got sidetracked by my work to make sense of all the distinct description templates, in various different languages, of various ages and many with their own set of bugs. I'm getting to the point where I can offer this template, which will function fully in various languages, tidies up several aspects, and will provide a level of consistency across potentially all description pages. At the moment I'm working hard to demonstrate compatibility with existing usage, to ensure it's absolutely not going to break anything. So, yes, this has taken me away from trying to understand and document the different types of way which there are, and has delayed my analysis of which tags apply to what. Tordanik has made some good points, which I'm trying to take on board. But if you can't wait a little longer, do change this back, and I'll have another go in a bit when I've got more analysis and a clearer assessment of which tags go where. Moresby (talk) 21:54, 26 March 2014 (UTC)
Just to help out on your understanding... in your first response above, you mentioned access=* ways as being about half open ways and half closed ways. But this tag should not be used to determine the overall statistics, as it's an additional property and not a primary feature. There are only a dozen or so primary features that may have both closed way and area as valid — I see the following listed on Map Features: some sport=* (free flying, running, toboggan, water ski), military=obstacle_course; highway=pedestrian, public_transport=platform, man_made=pier; tourism=artwork; amenity=planetarium(?!); and a few barrier=* types, which could include man_made=breakwater, historic=city_wall, natural=cliff, waterway=dam. As the likelihood is an extremely rare exception, I'm opposed to the closed ways icon; the existing way icon (which applies to open, closed, P, B/☊/?) is adequate, and these tags should mention use of area=yes and not further confuse with a closed way icon. --goldfndr (talk) 08:32, 30 March 2014 (UTC)

OK, I've been thinking about this a lot, and I'm going to withdraw this idea for now. Tordanik's comments have been useful, and those and others have prompted me to think about what I'm actually attempting to get across. I think that there is some value in attempting to demonstrate that some tags apply predominantly to open ways, and some to closed ways and/or areas. The comment "but a closed way is still just a way, so if something is valid on closed ways, wouldn't it also be valid on ways" is a particularly good point, and I think that there is a sense in which "used on a way" in some of these templates is understood as "used on a non-closed/non-area way". I think that there's more clarity which can be drawn here, but for now I'm going to go back to the analysis to see what the differences in usage are in practice. I think this will help identify different categories of usage, and then we can attempt to describe those in a meaningful and helpful way. Thanks for all your input. I'll come back with clearer case. :-) Moresby (talk) 10:43, 30 March 2014 (UTC)

Or maybe it should be like this:

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

EzekielT, 16:58, 17 July 2017 (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)

Reimplementation of KeyDescription and ValueDescription templates

I have substantially overhauled the {{KeyDescription}} and {{ValueDescription}} templates, with the new versions at User:Moresby/KeyDescription and User:Moresby/ValueDescription. I am looking for comments on this discussion page and would value any constructive contributions. Thanks. Moresby (talk) 18:57, 30 March 2014 (UTC)

Link to "other language discussion sections"

On the Portuguese translation of the template we had a link to the English (default) discussion page, I think this is useful for the translated pages as it highlights if there are discussions in other languages (primarily English). This is also of good help when local discussions starts to become technical, for quicker reference to English. --Skippern (talk) 16:37, 13 May 2014 (UTC)

status=inuse vs status=defacto

What is the difference, how should I use this? Can somebody please draw status lifecycle diagram? Xxzme (talk) 07:56, 12 November 2014 (UTC)

The documentation now states:
"in use" - "the feature is in use"
"de facto" - "Status indicating the tag is in widespread use, but no formal proposal process has taken place."
So the status "in use" can be added for any tag that is currently being used. I generally limit this to tag used by more than one mapper, and more than 100 uses for most features (unless it is a feature that is only expected to be seen less than few hundred or few thousand times in the world, eg place=sea), and use a different status for a tag that has only been used a couple of dozen times, or by one mapper / one import only.
The status "de facto" should be limited to tags that have been accepted by the community, show by common use by a large number of mappers in many different countries. Most of these tags have been used many thousands or millions of times, for a number of years, and most should be on the Map Features page already. --Jeisenbe (talk) 23:44, 7 July 2019 (UTC)

Rendering

Please see discussion at Template talk:Description#Rendering. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:49, 28 April 2015 (UTC)

Resolved: it seems that example rendering is now in the template Mateusz Konieczny (talk) 18:15, 15 April 2019 (UTC)

Edits since January 2015, consider reversion

I’m proposing rolling back this and some other pages to the beginning of this year at Template talk:Description#Edits_since_January_2015.2C_consider_reversion.--Andrew (talk) 06:35, 21 May 2015 (UTC)

Used on these elements link node

Why all the links from 4 objects are on the same page Node --AquaGen (talk) 09:03, 12 June 2015 (UTC)

Probably too old and stale - but it is unclear which links are problematic for you Mateusz Konieczny (talk) 10:27, 16 April 2019 (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)

The order of Implies and Useful combination

I don't like the order of Implies and Useful combination. Useful combination is more important and should be first. --geozeisig (talk) 14:46, 5 February 2016 (UTC)

No, i think it should not be changed. --Reneman (talk) 19:14, 5 February 2016 (UTC)
No, since you have to consider the order of 'requires', 'implies' and 'combination'. The first two have more formal character and should stay together, and their added importance is higher than useful combination. --Polarbear w (talk) 22:57, 5 February 2016 (UTC)
I have the same opinion as you Polarbear. The "Implies" says that combinations using the same implied tags may just be redundant and that we don't need them (unless there are some unknown cases to document where the implication should be moderated). "Implies" means that if this is false, we need discussions and changing these implications will require modifying tools using these data under those (limited) implicit preconditions.
In all other cases, there's an infinite number of possible combinations, and we just list a few of the most frequently used ones (for which it will be convenient to implement some presets in editors), but none of these combinations are implied and they are extensible.
"Implies" must be documented (generally this is because the tag is used to add some detailed semantics to another more generic tag, i.e the current tag is part of a derived subclass of the base class represented by the "implied" tags). "Useful combination" is not really necessary in tag descriptions, they will be used in derived subclasses of the class for the current tag, and those derived subclasses will be documenting their tag with an "implies" section linking to the current tag: in all object models, it's essential to document the parent classes as exhaustively as possible, but not all derived classes. — Verdy_p (talk) 11:38, 30 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).

Rendering of areas

With osmcarto-rendering and osmcarto-rendering-size you can show an example how the surface is rendered. But it is unclear in what size this should happen. To give an example: Tag:leisure=garden Tag:leisure=pitch

I think they take too much space and it would be better to show them in context. Leisure pitch has eg a frame. Often a pattern is also included which should not be reduced or enlarged (eg forest). Most existing examples of rendering have the size 125x125 pixels. And that is too big for the box.

There is no recommendation yet. It should really be fixed. For icons it has proven itself well, but for surfaces I would not agree.--geozeisig (talk) 09:42, 4 June 2017 (UTC)

I agree that they take too much space, but then I feel they should not be in the infobox to begin with. To me, that's mostly a concession towards Taginfo's limitations, not the best possible presentation on a wiki page. --Tordanik 10:31, 4 June 2017 (UTC)
For reference, affected revision looked like that: https://wiki.openstreetmap.org/w/index.php?title=Tag:leisure%3Dgarden&oldid=1467936 I suspect that something with reduced vertical size would work well Mateusz Konieczny (talk) 10:26, 16 April 2019 (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)

Rendering description

Currently using osmcarto-rendering parameter adds section named "Rendering". I propose to rename it to "Possible rendering" or "Rendering in osmcarto". It is far from the only and absolute rendering Mateusz Konieczny (talk) 20:35, 3 November 2017 (UTC)

Good point. Many mappers are too focussed on the carto style and complain that if "feature X is not pink" the world is out of balance.--Polarbear w (talk) 23:43, 3 November 2017 (UTC)
I modified descriptions for Polish and English ( https://wiki.openstreetmap.org/w/index.php?title=Template:Pl:ValueDescription&diff=prev&oldid=1520995 https://wiki.openstreetmap.org/w/index.php?title=Template:DescriptionLang&diff=prev&oldid=1520990 ) Mateusz Konieczny (talk) 11:36, 4 November 2017 (UTC)
I find Rendering in openstreetmap-carto is a lot too long. It should fit in one line. Maybe Rendering in carto would be enough?
In German it is Darstellung in openstreetmap-carto. But the link does not lead to a German page!--geozeisig (talk) 12:13, 5 January 2018 (UTC)

Just carto would not be enough since this is just the tool and not the style. The style is developed here. The DE link has been fixed now.--Polarbear w (talk) 14:06, 5 January 2018 (UTC)

This template is now supporting data items

Following the recent switch of {{KeyDescription}}, this template has now also been converted to support data items (wikibase). This should result in no immediate changes in appearance, except for a small gray pencil icon next to the description. Clicking it takes users to the corresponding data item where they can add description translations (we already had thousands of those). In some rare cases the description in the template might mismatch the one in the data item. In that case, a red pencil would also appear, offering to edit the current wiki page. Once TagInfo is migrated to use data items directly, all template parameters can be removed - e.g. a wiki page "RU:Key:Highway" will contain just this text: {{ValueDescription}}, and the template will get all the needed info, localized, from the data item. --Yurik (talk) 07:32, 7 December 2018 (UTC)

Thank you, very happy to see that the Wikibase project continues to make big progress! Quick question: Is {{DescriptionLang}} still the right place to edit translations after this change? --Tordanik 20:15, 8 December 2018 (UTC)
Tordanik, yes, I think that template is used for localizing {{Description}} itself, which is still being used. --Yurik (talk) 20:59, 8 December 2018 (UTC)

Possible errors for values without corresponding data items

EzekielT has rolled back the last change to this template with this comment: Errors started occurring for keys and tags without items... So I guess we'll have to wait for this to get fixed before we gain item support? . I do not know which specific keys/tags were affected, and which errors were observed, making it a bit hard to fix. There are currently about 180 such pages, and I suspect the user meant that the translation box at the top is showing incorrect values. I should have a fix today. In the mean time, please report any issues you see instead of just reverting (unless it significantly breaks a large number of items) -- it makes fixing them much harder. Also, every change to this template makes a heavy demand on the server, so we should change it sparingly if possible. Thanks! --Yurik (talk) 21:45, 8 December 2018 (UTC)

The issue has been fixed, and the new version is back in place. Please report any issues you spot on the talk pages. Thanks! --Yurik (talk) 03:13, 9 December 2018 (UTC)
Resolved: Seems ready for archivingMateusz Konieczny (talk) 18:13, 15 April 2019 (UTC)

Incorrect German translation

The current translation is incorrect. It should be

"Seite bearbeiten"
instead of "bearbeiten - seite"
"Datenobjekt bearbeiten"
instead of "bearbeiten - datenobjekt"

(Capitalization is mandatory in German)

Where can I correct it? --Tigerfell This user is member of the wiki team of OSM (Let's talk) 18:49, 14 December 2018 (UTC)

Tigerfell could you link to the page where you saw that? --Yurik (talk) 21:22, 14 December 2018 (UTC)

Yes, DE:Key:aerialway:drag_lift is an example. It is the label of the two pens for editing the description. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 22:59, 14 December 2018 (UTC)

Tigerfell, ah, the pencil tooltip, thanks for explaining. Yes, this was a bit of a hack because we don't (yet) have a "proper" translation string for that. I essentially made one up in the Module:DescriptionFromDataItem -- inside the function p.editLink - when template param text does not match data item text and it shows both pencil icons with their type (showType=True), it uses the Edit string plus the article or wikibase-entity-item strings, all lower case. We should not modify either one of those articles by hand. Instead, I will create a proper translation table, where people will be able to modify it. Plus I think the tooltip should include the actual text as stored in the Wiki template and in the data item. I really hope we can get rid of the template params, in which case this will no longer be needed. Thanks for the heads up about it. --Yurik (talk) 00:22, 15 December 2018 (UTC)

broken images

Why ValueDescription shows image in Tag:amenity=language_school despite that it is not specified and shows a wrong one? Mateusz Konieczny (talk) 13:20, 15 December 2018 (UTC)

I reverted recent template change, hopefully it will fix display of invalid images Mateusz Konieczny (talk) 13:21, 15 December 2018 (UTC)
Broken random image is no longer displayed Mateusz Konieczny (talk) 13:22, 15 December 2018 (UTC)

ValueDescription uses corresponding KeyDescription as a fallback for images, groups, etc. Most of the time it should be ok, allowing users not to specify the same info for every value of a key. Should I disable that, or is there another better approach? --Yurik (talk) 21:03, 15 December 2018 (UTC)

P.S. For now, disabling image fallback until we have a better solution. Some ideas - introduce a new property for keys called "fallback image" -- only used for values that do not have an image of their own. --Yurik (talk) 21:31, 15 December 2018 (UTC)
Resolved: This issue is resolved now and no unrelated image is now displayed at this item Mateusz Konieczny (talk) 18:12, 15 April 2019 (UTC)

Broken link

If the key consists of a composite value with a colon, the link will not be displayed correctly.

Example: Tag:theatre:type=amphi

The character ":" should have to be replaced in the link with "%3A".

A warning is issued in the editor: Warnung: Der Anzeigetitel „Key:theatre:type“ wurde ignoriert, da er nicht mit dem tatsächlichen Seitentitel gleichwertig ist.

--geozeisig (talk) 07:41, 27 January 2019 (UTC)

Regarding the warning: The template does not take the input for value, but instead looks for a key description (your page starts with "Tag"). This seems to be the error. Most interestingly, a page like Tag:aerodrome:type=airfield does not get this error. @Yurik changed the template recently, maybe he can help? --Tigerfell This user is member of the wiki team of OSM (Let's talk) 10:33, 27 January 2019 (UTC)
Thanks @Tigerfell and @geozeisig, someone has reported this already. This only happens when there is no data item (bot creates it with a delay). Debugging... --Yurik (talk) 16:56, 27 January 2019 (UTC)

fixed, plus a few more unit tests. --Yurik (talk) 03:01, 28 January 2019 (UTC)

Incompatible tags

Why is written in the infobox of transformer: Incompatible with building=* and voltage=* ? The voltage should be specified! --geozeisig (talk) 09:32, 3 June 2019 (UTC)

Because a transformer has several at least two voltages and you should tell which are the primary and the secondary.
A transformer is within a building it's not a building.
Nothing to do with a broken link IMHO --Nospam2005 (talk) 09:45, 3 June 2019 (UTC)
If you want to modify the content, I suggest you change the Data Item(de) Item:Q5254. Will fix some other issues on that page. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 09:53, 3 June 2019 (UTC)

default status should be draft or empty

I observed that the template was showing the status 'approved' when the status field was missing on the page. An empty status should be either not shown, or showing 'draft', as this is most likely the case when the status is unset. --Polarbear w (talk) 00:03, 5 February 2019 (UTC)

@Polarbear w could you link to the page where you saw this? Thanks! --Yurik (talk) 04:04, 5 February 2019 (UTC)
Hard to reproduce. It was on this version of the page. But last night yurikbot copied the now set status into Q5893 which applies to the old version also. So I tried to set up a [[1]] which plausibly shows 'unspecified'. But the test page has no item behind.
See Tag:building=sports_centre, has no status= but looks like "approved". --Hufkratzer (talk) 14:26, 5 February 2019 (UTC)
Thanks @Polarbear w & @Hufkratzer, turns out this was actually by design. building=sports_centre (Q6641) has no status (P6) value, but the "fallback" entity for the key itself - building (Q108) has its status set to approved. I could disable falling back for statuses, but than why set the status on a key? Unless of course we want to have a strict separation between "enum-like" keys and the "non-enum" keys. For example, enum-like "building" or "religion" keys have a semi-well known list of allowed values - and each value must have its own status. The "non-enum" like "address" would have no statuses on the values? In the mean time, I will disable fallback for the statuses. Thoughts? --Yurik (talk) 16:29, 5 February 2019 (UTC)
Too late tonight to think about the handling of non-vs-enum keys. The building page now shows 'unspecified' which seems the most logic for an unspecified status. --Polarbear w (talk) 00:26, 6 February 2019 (UTC)

Add incompatibilities

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

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

truncation of changeset comments

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

building=office implies office=* ?

Here Yurikbot has added that building=office Implies office=* with comment "Auto-updating from Wiki pages". But I can't see that this is or was claimed in the source of the wiki page Tag:building=office. Why was that added? --Hufkratzer (talk) 21:05, 6 April 2019 (UTC)

@Hufkratzer because of PL page. Thx for keeping tabs :) I posted an explanation of this on wiki talk. --Yurik (talk) 21:36, 6 April 2019 (UTC)
This is a technical explanation, but IMHO it doesn't make sense to do it like that. I can't read Polish and I don't understand why building=office should imply office=*. --Hufkratzer (talk) 13:15, 7 April 2019 (UTC)
This particular case of damage seems to be fixed now Mateusz Konieczny (talk) 18:10, 15 April 2019 (UTC)
Resolved: This issue is resolved, though it may make sense to start more general discussion about not showing data from data items Mateusz Konieczny (talk) 18:11, 15 April 2019 (UTC)

Matching "Norsk" description and data items

Apparently No:Tag:amenity=marketplace has a description which does not match the Data item. If you remove the description of the wiki page, the template displays the English version. It should actually display "En plass hvor det foregå handel, f.eks et torg". --Tigerfell This user is member of the wiki team of OSM (Let's talk) 20:32, 12 April 2019 (UTC)

@Tigerfell it seems "no" is not recognized as a valid language code by mediawiki. Moreover, the https://no.wikipedia.org is actually in language code "nb" - Norwegian (Bokmål) language according to this table. I have added a unit test to Module:OsmPageTitleParser, and added it to the list of our custom languages at Module:OSM Constants. --Yurik (talk) 22:54, 12 April 2019 (UTC)
As far as I understand, there are apparently two languages in Norway (?), but we just have one in the wiki and data items. Thanks. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 10:24, 13 April 2019 (UTC)

Name is not required but useful.

In many info windows there is now Requires = name although the tag requires was not used (see: amenity=bar or many others amenity but not all). The name in this case is not required but useful.

How is this phenomenon explained? Can you turn this off again?--geozeisig (talk) 05:54, 13 April 2019 (UTC)

Same explanation as above: Yurik's bot has copied it from Pl:Tag:amenity=bar to Item:Q4892 (here) and now the template displays it in all wiki pages. I don't like this confusing system at all. IMO the template should only display what is on the wiki page itself and additionally hints if this conflicts with other wiki pages. --Hufkratzer (talk) 12:06, 13 April 2019 (UTC)
I also would prefer to avoid such data leaks and display only what is on the wiki page itself. Mateusz Konieczny (talk) 18:04, 15 April 2019 (UTC)
I edited item at https://wiki.openstreetmap.org/w/index.php?title=Item:Q4892&diff=prev&oldid=1842733 - but for now it is still displayed. Maybe it will disappear soon, but I am not happy about that misleading information that requires editing completely unrelated page to fix it. Mateusz Konieczny (talk) 18:08, 15 April 2019 (UTC)

How one may hide unwanted image description

[4] was necessary to hide unwanted image caption. Unfortunately it adds completely pointless and useless image caption. But removing it causes "Αυτοκινητόδρομος" to appear. How one may get rid of it without adding pointless caption? I guess that it leaks from data items, as it is not specified anywhere at the page Mateusz Konieczny (talk) 18:02, 15 April 2019 (UTC)

I am planning to remove forceful insertion of caption from source external to Wiki page. Is anyone opposed to that? Mateusz Konieczny (talk) 10:24, 16 April 2019 (UTC)
I object unless someone explains calmly why this is a good thing. --Andrew (talk) 10:33, 16 April 2019 (UTC)
Tag:highway=motorway currently has the infobox with pointless border making already small image even smaller. It is cause by showing useless caption. Currently it is not removable. Compare size of image with for example Tag:cycleway=crossing. It would be desirable to make image more legible. Mateusz Konieczny (talk) 10:45, 16 April 2019 (UTC)
I agree that these image captions are not useful, and it seems somewhat broken that a Greek caption has any effect on English pages to begin with. --Tordanik 17:57, 16 April 2019 (UTC)
I suspect this is due to the module falling back to any available image description when English is missing. What would be preferable - to show nothing if only greek/french/german text is available, or to only show "local or english", and no other options? Showing just the local text would encourage users to translate it to english, where as not showing anything at all would make people less likely to add it. But again, this is really up to the community how we want to handle that. Removing non-english fallback is relatively easy. --Yurik (talk) 17:17, 29 May 2019 (UTC)
Never show any description. If image needs description than it is a poor fit for the lead infobox image. Can someone give an example of case where displaying smaller image and additional text actually makes sense and is better than switching to a proper image? Mateusz Konieczny (talk) 17:59, 29 May 2019 (UTC)
A general description of what the image is about satisfies curiosity (what am i looking at?), and also good for visual impaired people (usability). image caption is not a replacement of the description. --Yurik (talk) 18:13, 29 May 2019 (UTC)
alt text may be useful, but good alt text would be rarely the same as image description aimed at people who can see the image well. "satisfies curiosity (what am i looking at?)" I am pretty sure that it is well covered by ability to click an image and see its description page. Can you link to tag documentation page where image description is desirable (preferably with English language description)? Mateusz Konieczny (talk) 18:22, 29 May 2019 (UTC)

Where this template may be edited?

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

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

Script errors based on input

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

Fixed the Ko:Key:wikipedia case -- it was actually an error in the template parameter - group was given as a link rather than a string, but now the code will handle it. --Yurik (talk) 23:17, 29 May 2019 (UTC)

status=depreciated

IMHO, we should add depreciated is the documentation about the possible values of status. This status makes sense and is already used like here. —Preceding unsigned comment added by Nospam2005 (talkcontribs) 08:43, 30 May 2019

☑Y Added all of the missing values to the English documentation. There is deprecated already. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 09:18, 30 May 2019 (UTC)
The status deprecated is in the documentation, does it need more?--Andrew (talk) 09:38, 30 May 2019 (UTC)

move statuslink after all status values

currently the order in the doc is :

status: the approval status of this feature; possible values include:
statuslink: name of the proposal page, for linking
status1
status2

it should be :

status: the approval status of this feature; possible values include:
status1
status2
statuslink: name of the proposal page, for linking

I can fix it, but the doc page request to talk it here first :) Marc marc (talk) 11:04, 7 June 2019 (UTC)

I think you are right. --Hufkratzer (talk) 11:14, 8 June 2019 (UTC)
Resolved: done Marc marc (talk) 14:38, 8 June 2019 (UTC)
I do not think you would have needed to ask for such a small change in the documentation. This box is put on the doc page along with the rest of the documentation, but it is actually about the documented template itself. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 15:02, 8 June 2019 (UTC)
so the warning should be removed on the doc page ? Marc marc (talk) 20:44, 13 June 2019 (UTC)
If you think that warning is confusing you may improve/propose to improve wording of Template:Heavily used template Mateusz Konieczny (talk) 10:08, 14 June 2019 (UTC)
I think {{Heavily used template}} could be moved from {{ValueDescription/doc}} to {{ValueDescription}} ("...<noinclude>{{Heavily used template}}{{documentation}}</noinclude>" ). Then it would be more clear that the warning belongs only to the template itself. --Hufkratzer (talk) 10:25, 14 June 2019 (UTC)
I do not see a benefit in changing this. It even says "This template is used on a lot of pages!". --Tigerfell This user is member of the wiki team of OSM (Let's talk) 14:37, 14 June 2019 (UTC)

merge de facto <> defacto

right now the doc contains 2 lines

de facto: not an approved feature, but commonly used in the map
defacto: the tag is in widespread use, but no formal proposal process has taken place

I plan to merge both lines in

de facto or defacto: no formal proposal process has taken place but the tag is in undisputed/widespread use

or just drop "defacto" ? Marc marc (talk) 21:11, 13 June 2019 (UTC)

What is "undisputed use"? Why not just adapt it to what is in Item:Q13? --Hufkratzer (talk) 10:01, 14 June 2019 (UTC)
No one reasonable is going to dispute that this tag is standard for tagging given feature (say highway=motorway) Mateusz Konieczny (talk) 10:06, 14 June 2019 (UTC)
I would drop defacto Mateusz Konieczny (talk) 10:06, 14 June 2019 (UTC)

I guess this is about changing only the documentation as well. I introduced one of the lines based on a question of System-users-3.svgNospam. I wanted to document all possible values you can insert and this included the spelling variation de facto. You can verify this by checking Template:StatusLang and you will find the line |de facto|defacto=... meaning that they use the same translation strings and additionally, Data items just lists one status. I guess I missed this, probably because one value was documented already and the other was not. I am going to fix it then. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 15:05, 14 June 2019 (UTC)

Thanks Tigerfell, that was helpful. I believe "De facto" is a very useful status. The alternative, "in use", is non-specific and the definition can fit a tag used by only a handful of users, a couple of hundred times. It's helpful to have the "de facto" definition for tags used millions of times and considered the de-facto standard, e.g. highway=motorway/primary/secondary. --Jeisenbe (talk) 23:38, 7 July 2019 (UTC)