Template talk:Description/Archive 1

From OpenStreetMap Wiki
Jump to navigation Jump to search

taginfo broken for tags with :

For example taginfo from https://wiki.openstreetmap.org/wiki/Key:teryt:simc links to https://taginfo.openstreetmap.org/keys/teryt%253Asimc rather than https://taginfo.openstreetmap.org/keys/teryt:simc Mateusz Konieczny (talk) 01:34, 28 October 2017 (UTC) Seems to be caused by Template talk:DescriptionLinks Mateusz Konieczny (talk) 01:41, 28 October 2017 (UTC)

There's NO such "%253A" in the generated URL and the link is working correctly (and correct for the URL standnard). There was a problem previously because of the URL path encoding with some tags using non-ASCII characters and this was fixed. However I can also unencode the "%3A" back to ":" if this ever causes problems (it does not on TagInfo: this is still standard URL path encoding, which is really used by web browsers internally when it canonicalizes an URL path to perform actual web requests).
So there's no issue at all with tags that contain a ":".
Sorry I see that the issue was not in the Taginfo box but in the additional Taginfo links. Yes this is PATH encoding here instead of URL encoding, so yes the URLENCEODE was needed there, but it PATH-encoded some characters (there was already an exception for the "/", I added the ":"). Note that this encoding is different from the one used in Taginfo box, where the tag is within a query string parameter and so it is URL-encoded there (using "%3A" correctly for the ":") and not PATH-encoded.
Note that the other fixes I did was also to actualize the list of working TagInfo instances by testing those that are really working and remove those that are dead now. I also made thme correctly use HTTPS where available, and updated the doc. I'll add now a test example in the doc page about tags with ":" in them. — Verdy_p (talk) 10:13, 28 October 2017 (UTC)
Now it works correctly, I am not sure what is the cause of this change. Mateusz Konieczny (talk) 17:05, 28 October 2017 (UTC)

Edits since January 2015, consider reversion

I find some of the edits during this year to the templates {{Description}}, {{KeyDescription}}, {tl|ValueDescription}}, {{RelationDescription}}, {{DescriptionLang}} and {{StatusLang}}, also the documentation subpages {{Description/doc}}, {{KeyDescription/doc}}, {{ValueDescription/doc}}, {{RelationDescription/doc}}, {{DescriptionLang/doc}} and {{StatusLang/doc}}, to be of low quality and not improvements to the carefully thought-out and multilingual set of templates. Therefore I propose to roll the templates back to their state on 1st January, only keeping translations of keywords into more languages and changes that can be defended as improvements. Sorry if I haven’t appreciated the benefits of any edits.--Andrew (talk) 18:45, 18 May 2015 (UTC)

Also {{ElementUsageLang}} and {{ElementUsageLang/doc}}. Any blocked users who want to comment can post on the Wiki team forum.--Andrew (talk) 05:02, 19 May 2015 (UTC)
Please be more specific: Which parameters would be affected or removed; and what else would change? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 07:57, 19 May 2015 (UTC)
I’m not pointing to individual edits because I believe people should be given a second chance but specific issues include variation in the colours of infoboxes and depopulation of Category:Cs:Czech Documentation. I am also concerned about a possible control agenda in some edits that sees the quality of OSM’s tag documentation as acceptable collateral damage, and this may have led to side effects that I’m unaware of.--Andrew (talk) 06:17, 20 May 2015 (UTC)
I'm not asking you to point to individual edits; I'm asking you to detail the changes you prose to make. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:58, 21 May 2015 (UTC)
I want to roll the seven templates I named and their documentation subpages back to their state at the beginning of this year, only keeping changes established as beneficial in this discussion (currently extra translations and statuslink) and reverting the others whole.--Andrew (talk) 17:52, 21 May 2015 (UTC)
I know you do; I read what you wrote above. I've asked you more than once now to describe in detail what the effect of doing that would be. You seem surprisingly reluctant to do so. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:24, 21 May 2015 (UTC)
The changes I want to roll back are the ones in the page histories of the pages I’ve listed; although I haven’t completely analysed one or two of them, regressions reported on the editor’s talk page make it clear that they didn’t understand the full effects either. Again, I don’t think it’s helpful to name individual editors here as it may hinder them from constructive work in the future.--Andrew (talk) 11:55, 22 May 2015 (UTC)
I believe the use of the old parameter statuslink (added in January 3rd) is okay, and I think it's better than a link in the page. --Jgpacker (talk) 14:33, 19 May 2015 (UTC)
Oppose per the lack of answer to my qeustion above. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:24, 21 May 2015 (UTC)
Well, I would be glad if my Category:Cs:Czech Documentationwould work again. I do not know why it stopped working and I suspect the recent changes has broken something. Chrabros (talk) 06:44, 22 May 2015 (UTC)

The changes since January have been (excluding those already reverted):

    1. Link for statuslink parameter (to be kept).
    2. Change of colour to white to stop an argument, not as a considered change.
    3. Massive rearrangement of whitespace that broke relation descriptions and makes extensive other changes harder to follow.
    4. Depopulation of Category:Cs:Czech Documentation.
    5. Removal of link to source for images.
    1. Low-value fiddling.
    1. Low-value fiddling.
    1. Hurried workround to changes to {{Description}}.
    1. Additional translations to Japanese (to be kept).
    2. Ordering by string instead of language (need to consult translators whether good).
    3. Additional links to Elements across languages + correction in Czech (to be kept).
    1. Ordering by string instead of language (need to consult translators whether good).
    2. Updated translations to French and Czech (to be kept).
    1. Ordering by string instead of language (need to consult translators whether good).

--Andrew (talk) 18:56, 25 May 2015 (UTC)

Many of the partisan descriptions above amount to "The changes have been changes". In the absence of more useful descriptions - and veiled threats notwithstanding - I remain opposed to a wholesale rollback. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:26, 25 May 2015 (UTC)
Overall I agree with the reverts proposed. Fiddling with whitespace seems to be mostly scratching an itch, but it's too easy to break something and was made in a way that makes it costly to review. Also, I think ordering by language is better, because otherwise a translator may easily miss other strings. --Jgpacker (talk) 02:23, 26 May 2015 (UTC)
What is your view as a Portuguese speaker of the use of pt | pt-br = collapsed together in the changed translation templates?--Andrew (talk) 06:13, 26 May 2015 (UTC)
It's ok if they really are equal, but preferably it should be done by a native portuguese speaker if they don't already have the same translation. If there was only one of them with a translation, and another was added without review by a native speaker, then it should be reverted, but if they were already equal and they were collapsed like that, then I would guess it's okay. --Jgpacker (talk) 13:13, 26 May 2015 (UTC)
Even if there's a single reviewer for one version, it is still preferable to create it for both versions of the language, otherwise one will see a portuguese message, and another will just see the default English fallback (which is worse even if there's a need for a small change for the second version). Mutual understanstanding is warrantied between the two variants of the language (and in fact, both countries have agreed now to accept mutual additions or variations in normal usage; there's no longer separate terminlogies required). On Wikipedia, both versions are equally accepted. In my view, maintaining two versions on this wiki is just a loss of time and efforts.
The situation is a bit different for "zh-hans" vs. "zh-hant", because this wiki still does not feature the automatic transliterator used on Wikipedia, so a single "zh" version still does not work properly).
However we don't need "zh-tw", "zh-cn", "zh-sg" (which were used on Wikipedia and are now highly deprecated in favor of distinction of script variants).
For the same reason, we don't need "md", or even "ro-md", but we may need "ro-cyrl" for Moldavian (however script transliterators would work better), which is in fact written there in both Latin and Cyrillic script (and no real difference in Latin with Standard Romanian; "Moldavian" was invented in the 1950's in USSR and there was then attempts to integrate Russian terminology in it; this failed, and in fact Moldavians are either using the standard Russian language directly, or the Romanian language only transliterated automatically to Cyrillic, or standard Romanian in the Latin script; Romanian just uses the basic Latin alphabet with a diacritics for two additional consonnants; these combined letters are unambiguously converted to Cyrillic; some Cyrillic letters are not easily transliterated to Latin, but actually not used for Moldavian, they are used only for Russian or Bulgarian terms...). So it would be fair to support here "ro-cyrl" for Moldavian, in addition to "ro", only because we still don't have transliterators in this wiki, but more importantly because automatic transliterators will break many pages containing English terms or terms in other Latin-written languages than Romanian. As well the transliteration from Cyrillic would break Russian and Bulgarian words (which should still not be transliterated). A transliterator may work on this wiki in the future, but only if we can properly tag all multilingual contents with the correct language code (so that only Romanian/Moldavian will be affected, but not everything else). Transliterators could also be implemented only in wiki editors to help contributors, but only if they save in appropriate pages tagged with "Ro:" or "Ro-cyrl:" prefixes in page names. However it is not worth the effort, given the very small number of real contributors for Moldavian (that prefer in fact contributing only in standard Russian or standard Romanian). Moldavian supporters are in fact very few, and this is a very small country whose population is divided between pro-Romanians, and pro-Russians, and in fact little support for "Moldavian" as a separate entity (this distinct linguistic support has only existed for a couple of decenials, and stopped long before the collapse of USSR; now only the nationality/ethnic concept remains but local communities prefer supporting standard Romanian or Standard Russian... or both, without mixing their respective scripts).
(this is not the case for Serbo-Croatian whose division is now effective and increasing between dual-scripted Serbian, Latin-only Croatian... and Latin-only Bosnian, another recent creation mixing some aspects of "pure" Croatian, "pure" Latin-Serbian, and some aspects borrowed from Albanian in an attempt to unify the country)...
As well, it is still necessary to maintain separate Latin and Cyrillic versions for Serbian (a transliterator could do the job, but this would cause problems if applied blindly on a complete page). — Verdy_p (talk) 16:36, 26 June 2016 (UTC)

The changes to documentation subpages since January have been (excluding those already reverted):

    1. Changes to documentation of status parameter (deserves a separate review).
    2. Addition of editing warning (to be kept).
    3. Adjustment of wiki syntax (to be kept).
    1. Tidying of documentation and additional explanations (to be kept).
    2. Addition of editing warning (to be kept).
    1. Addition of editing warning (to be kept).
    2. Adjustment of wiki syntax (to be kept).
    1. Adjustment of wiki syntax (to be kept).
  • To {{DescriptionLang/doc}}:
    1. Table of translations flipped (columns were languages, now translations).
      This is the most important change: there were already too many columns and with the table restricted width, not only you had to scroll horizontally, but all texts were split on multiple lines with one or two ords per line.
      In addition the code to do that was huge and contained errors caused by incorrect copy-pasting. Now it is much shorter and simpler: you can also add some translated languages easily by editing ony one line, and the tables are readable. Note that this table is actually not part of the doc, it is just a testcase shown at end of the doc to get a status of existing translations; the template is not used this way anywhere else.
      I am definitely not convinced this is "poor quality" but really improved quality (with easier maintenance as well) and it was absolutely not a change of the template itself (since when doc pages are templates? There are many templated having absolutely no documentation on this wiki and never tested with enough test cases). Ideally even this long table should not be part of the /doc subpage but of a testcase subpage (initially it was in /table to visit via a link from the doc page, but for now it has remained for now in the /doc page, as it was). — Verdy_p (talk) 15:26, 26 May 2015 (UTC)
  • To {{StatusLang/doc}}:
    1. Table of translations flipped (columns were languages, now translations).
      Same remark. — Verdy_p (talk) 15:26, 26 May 2015 (UTC)
  • To {{ElementUsageLang/doc}}:
    1. Table of translations flipped (columns were languages, now translations).
      Same remark. — Verdy_p (talk) 15:26, 26 May 2015 (UTC)

--Andrew (talk) 06:13, 26 May 2015 (UTC)

  • Note also that these translations (in the template, not the doc page) were really bad and unmaintained, or just copying English because these translatable strings were added at different time, but not maintained the same way across languages. It is much safer to keep each translation per resource. This allowed to add correct transaltions that were missing, without having to duplicate them. For example pt and pt-br were already copies of each others (except one that was showing English). switching first by resource name than by language allows simpler maintenance of each resource, even if for a new language this means editing in several places (but there's no need to add any #switch, the translators use the same model used for translatable switchs: they just insert a single line with the leading language code, and can easily add fallbacks (such as "pt|pt-br=" or "zh-hans|zh-hant=" when they are the same: if it is neexded to separate them, it is easy to duplicate that line, separate codes, and edit one of them, like in all other translated templates). Other fallbacks better than English can also be easily specified (e.g. "fr|br|oc=" to reused the same French resource when the "br" or "oc" resources are still not there)
  • Also the last resources at end were actually not translated at all in most languages (they used "TranslateThis" multiple times), now the "TranslateThis" is factorized just to the default line and does not need to be edited). Language fallbacks are useful in all translated projects (before the flip, the only fallback possible was to English).
  • If you want to add new items to translate, you don't need to review all the existing translations and update them; add the resource with a single TranslateThis English fallback, and add a single line for a language you know without assuming that the English fallback will be used always. Translators also don't have to translate everything, they translate item per item, without copying blocks. Overall the code size is also even smaller, and translations occur within the context of a single translation unit (exactly like in ".pot" files, Translatewiki.net, CLDR survey, or other translation projects: this is the standardized way where we work unit by unit).
  • Final note: the TranslateThis template generates an image and a link that does not fit correctly in translations that are used in "title=" attributes for showing hints, this generates incorrect HTML or incorrect wikisyntax. the including of the TranslateThis template should be conditional (there were cases were this broke the generated page in some language that were incompletely translated). For now I've not found any way on this wiki to filter out the HTML presentation in resources that are used in a way supporting ONLY plain-text without any additional HTML element or link, as this wiki does not have this filtering capability). Only in some cases, for specific resources, using TranslateThis may be safe (but the target of the link is still wrong). In my opinion, the icon and link should not be used, and the Description box templates should just include a single small "translate" link in the box, showing where it is translatable: the link can just point to the box template page showing the lists of templates containing translatable resources in its documentation. — Verdy_p (talk) 16:11, 26 May 2015 (UTC)

Missing templates

You overlooked {{El:KeyDescription}} and {{Pt-br:KeyDescription}}. --Andrew (talk) 09:56, 20 April 2014 (UTC)

Rats, they've come in since I started, and I'd not noticed them. :-( Thanks - I'm impressed! Moresby (talk) 12:04, 20 April 2014 (UTC)
Also {{KeyDescription no translation}} and {{ValueDescription no translation}}. --Andrew (talk) 14:56, 20 April 2014 (UTC)
And {{Wertbeschreibung}}. --Andrew (talk) 18:03, 20 April 2014 (UTC)
Resolved: deleted or archived Mateusz Konieczny (talk) 22:29, 9 January 2021 (UTC)

Thank you for doing this

This discussion was moved from User talk:Moresby.

The templates with the Pt-br: prefix needed maintenance and nobody knew or had the time to fix them. Thanks for doing this work. --Jgpacker (talk) 20:51, 23 April 2014 (UTC)

You're welcome - and it's really kind of you to say so. Thank you. Google translate suggests: "Seja bem-vindo". :-) Moresby (talk) 20:36, 23 April 2014 (UTC)
Actually it's "De nada" haha (it's the second translation that google suggests). "Seja bem-vindo" mean something like "you are welcome to this place". --Jgpacker (talk) 20:51, 23 April 2014 (UTC)
You see, this is why I leave it to the experts. :-) Moresby (talk) 20:52, 23 April 2014 (UTC)

Resolved: also thanks from me Mateusz Konieczny (talk) 14:24, 10 January 2021 (UTC)

Why statuslink is present in documentation but not used in template?

Open questions:

  • Should pages outside English namespace link to English proposal?
  • What if Proposal wasn't translated in page language? Should we link to English proposal? Should we show red link?
  • If proposal is in Multiple languages, which of them 'main'?

first appearance in docs. 02:34, 12 December 2014 (UTC)

I think the parameter statusLink should be available in the template, but it doesn't quite seem like it's either ever been added -- or added back after some refactoring was done. I can't tell. However, either way, to answer your questions from my subjective point of view. I think pages outside the English namespace should (at least for the time being) link to the English proposal. It seems the most natural as the majority (all?) proposals are in English, though the process doesn't say anything about this being a requirement. This extends to point #2, and here I feel the same way: for the time being, simply link to the main proposal page. It shouldn't do anything else, nor care about namespace -- the main proposal page only exists in one location and language, from what I've mostly seen. The main one would be the proposal composed by the original team/author, as deemed by the submitter. Messy Unicorn (talk) 03:42, 1 January 2015 (UTC)

Resolved: it is used nowadays

Mateusz Konieczny (talk) 22:27, 9 January 2021 (UTC)


Could we include rendering, as seen, for example, in Tag:historic=memorial#Rendering, in a table in this template? I've made the template {{Rendering}}, which may help. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:14, 27 April 2015 (UTC)

Ooh, I quite like that! Moresby (talk) 20:30, 27 April 2015 (UTC)
OK, I've implemented that in this template, and on the above article. As you can see, the table markup has gone awry. Can anyone fix it, please? Otherwise, feel free to revert me and I'll try again later. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:25, 27 April 2015 (UTC)
I don't think that the infobox is the right place for rendering. In my opinion, the infobox needs to be somewhat short to be useful, which is hard to achieve once the list of projects becomes longer. But perhaps more importantly, many features cannot be displayed as a mere icon, there needs to be more room to also allow area features and the like. This means that a gallery on the body of the wiki page would be a much better solution. I have therefore reverted your additions for now. Let's discuss this for a bit more than 6 hours before deciding on a solution. --Tordanik 09:12, 28 April 2015 (UTC)
And many can be displayed as an icon; since the parameter is optional, it can be used where suitable, and not otherwise. Where icons are available it makes sense to have them in place which is predictable and machine-parsable. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:51, 28 April 2015 (UTC)
Ok, I'm going to explain my point of view in some more detail:
  • I agree that the location should be predictable. But displaying the rendering in different places, depending on whether it's rendered as an icons or a larger area, is not predictable. It would be much more consistent to always have a rendering gallery in a "Rendering" subsection after "How to map" and "Examples".
  • I believe that it's not a good idea to have all these images uploaded manually. It would be better to automate this, and therefore ensure that the rendering being displayed is always the latest one. Therefore, I think you have it backwards: Ideally, the rendering data would not be readable by machines, but written by machines (e.g. based on Taginfo's project feature or, if Jochen is not interested in that, a different database).
What's your opinion on this? I hope we can still make progress through discussion rather than a revert war. --Tordanik 12:21, 28 April 2015 (UTC)
I agree with given points. Previously we were placing only current and most popular renders at wiki. Today there way more programs that use OSM data (most recent ones OSMAnd and maps.me)
You may be surprised, but many wiki readers used to different renders than presented at Tag:historic=memorial#Rendering right now.
I wish we had option to store user preferences in cookies and only display preferred renders per each visitor. But this is challenging task to do at wiki AFAIK. Xxzme (talk) 14:33, 28 April 2015 (UTC)
I'm not in the least surprised; that's why I made a template which can be expanded as the community sees fit. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:48, 28 April 2015 (UTC)
The template I created can also be written by machines. It would also be possible to extend it, or to create an alternative, for linear and area renderings. Wikis are intended to be improved incrementally. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:48, 28 April 2015 (UTC)

The changes I made have now been reverted by an admin, who has also protected the page. What shocking behaviour. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:48, 28 April 2015 (UTC)

The shocking behaviour begins with your edit (1). Please vote for your changes only after all (lists.openstreetmap.org). We will not argue. And we do not need editwar in an important template! In addition caused your extension errors. Read in German. --Reneman (talk) 21:31, 28 April 2015 (UTC)
Your comment is nonsensical. What are you trying to say? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:24, 28 April 2015 (UTC)
Resolved: it seems that example rendering is now in the template Mateusz Konieczny (talk) 18:15, 15 April 2019 (UTC)

Unlinked image

The image was recently changed such that clicking it doesn't lead to the original picture (with [[{{{image|}}}|200px|link=]]). The image should be linked or have a link to its full size version and attribution. Mrwojo (talk) 15:29, 23 May 2015 (UTC)

This link change was unexpected, the "|link=" part can be removed without problem (but it was already present in some other parts of the template for other icons). — Verdy_p (talk) 15:17, 26 May 2015 (UTC)
As there were three comments above requesting the restoration of the link, I restored it (but not for the other icons which all used the empty "|link=" parameter). If you wish you can add "|image_caption=" (optional); however this parameter is still not used in the 3 main templates using Template:Description (for relations, tags, or features). — Verdy_p (talk) 17:23, 26 May 2015 (UTC)
Resolved: seems solved Mateusz Konieczny (talk) 14:23, 10 January 2021 (UTC)

Remove User:Moresby links from See Also

On Template:Description on section "See Also" are three links to the User:Moresby namespace. I guess they can be removed now?--Jojo4u (talk) 12:13, 22 May 2016 (UTC)

I removed them.--Jojo4u (talk) 19:10, 22 October 2016 (UTC)

Resolved: Mateusz Konieczny (talk) 21:42, 9 January 2021 (UTC)

Separating usage and proposal status

I started a discussion about separating usage and proposal status in this template: https://forum.openstreetmap.org/viewtopic.php?id=56126

Resolved: external discussion about such topics is not really relevant, please discuss such things on wiki Mateusz Konieczny (talk) 22:00, 9 January 2021 (UTC)

Adding tag evolution chart link

Recently there is a permalink functionality available to show a chart. This is provided by the tool TagHistory.
Example: https://taghistory.raifer.tech/#***/building/ to show a chart of the key building=*
Could it be worth to add a corresponding link to templates (Template:Description / Template:ValueDescription) in the section "Tools for this tag" (next to taginfo · overpass-turbo)? --MalgiK (talk) 18:53, 18 February 2020 (UTC)

I think TagHistory is great, and would be happy to see it added eventually. But first we need to confirm if the maintainer of the tool can get it on a regular update schedule. The data was last updated 12 months ago. --Jeisenbe (talk) 12:07, 19 February 2020 (UTC)
I agree, it would be nice to have a regular update schedule, even if it would happened once a year. I assume this is the corresponding talk: Blacktocat.svg data updates #10 --MalgiK (talk) 13:38, 20 February 2020 (UTC)
Given that it sadly was not updated and taginfo got chronology mostly replacing it - I think that it can be safely rejected and marked as resolved, right? Mateusz Konieczny (talk) 07:36, 13 November 2020 (UTC)
Good point. Is there a way to pulll in one of the charts shown in taginfo directly? It's a shame if taghistory is never updated again, since it is useful for rare tags and for comparisons. --Jeisenbe (talk) 03:02, 14 November 2020 (UTC)
Was also happy about the new taginfo "chronology" tab, and thought about to add a additional direct link to it for the infobox. But it seems the chart drawing is only done for tags/keys which have reached an amount of app. 1k items (and the compare function to draw two line in the chart would be also nice for taginfo). "Is there a way to pull in one of the charts shown in taginfo directly" Yes, should be possible, e.g. link: https://taginfo.openstreetmap.org/keys/motorroad#chronology --MalgiK (talk) 14:48, 14 November 2020 (UTC)
Oh sorry miss-understood it, direct link seems working, but if it could be "embedded" i don't know. --MalgiK (talk) 14:52, 14 November 2020 (UTC)
Adding chart directly to infobox seems unfeasible, and separate link is no longer useful - taginfo has this for popular tags and this tool is not being updated. Close as fixed by taginfo? Mateusz Konieczny (talk) 10:21, 7 January 2021 (UTC)
Resolved: Mateusz Konieczny (talk) 21:58, 9 January 2021 (UTC)

Move Wikidata link to the bottom

It is clearly less important than taginfo statistics, if present at all it should be at the end of the infobox. I propose to move it there. Mateusz Konieczny (talk) 11:35, 11 May 2020 (UTC)

I plan on doing it relatively soon. Mateusz Konieczny (talk) 08:40, 10 September 2020 (UTC)
I would not change it back, then the list would even come a little closer to the alphabetical order ;-) --MalgiK (talk) 18:44, 10 September 2020 (UTC)
I support this change (or better yet, remove the link entirely). --Jeisenbe (talk) 05:51, 23 October 2020 (UTC)
I support moving it to the bottom. And I don't mind removing it. maro21 14:05, 24 October 2020 (UTC)
I moved it two levels down. maro21 23:19, 12 November 2020 (UTC)
Moved it all the way down, And I don't mind removing it either. --MalgiK (talk) 07:15, 13 November 2020 (UTC)
@MalgiK: thanks! Mateusz Konieczny (talk) 21:58, 9 January 2021 (UTC)
Resolved: Mateusz Konieczny (talk) 21:58, 9 January 2021 (UTC)

Can we remove this weird manual styling?

For some reason this page is manually set to have colored background. Is there some reason for that? It seems to be caused by <div style='clear:both; margin:1em 0; border:1px solid #aaa; background:#ecfcf4; padding:.5em'> code. Mateusz Konieczny (talk) 10:25, 7 January 2021 (UTC)

Removed Mateusz Konieczny (talk) 21:41, 9 January 2021 (UTC)
Resolved: Mateusz Konieczny (talk) 21:59, 9 January 2021 (UTC)

native_key and native_value

This discussion was moved from above.

I would like to see two extra parameters. native_key and native_value. This will allow us to add the names of the key and value in the language of the user and enable him to find a key or value in his language. See Polish version of any tag. --Władysław Komorek (talk) 21:16, 30 March 2014 (UTC)

Keys and values are a machine-readable constant. They must not be translated, otherwise they no longer work. (I assume we were supposed to discuss below the box? Feel free to move my comment down.) --Tordanik 16:27, 31 March 2014 (UTC)
I do not mean their translations, only adding additional, optional, parameters, where the user enters a names in their own language. --Władysław Komorek (talk) 16:34, 31 March 2014 (UTC)
Then why do you insist on calling them "key" and "value"? The last time you suggested this, I've given a lot of suggestions on how to do this without this misleading presentation format, and even without the limitation of having only one possible native word for each key. --Tordanik 16:40, 31 March 2014 (UTC)
I also replied to you that your suggestions do not solve the case.
It seems that you do not accept a different approach to help users, who do not speak English, select the appropriate tag. --Władysław Komorek (talk) 18:34, 31 March 2014 (UTC)
You indeed declined all alternatives I offered, but I still wonder why. These are what the German community uses, and I don't remember anyone ever asking for a list with entries like Straße=Autobahn. I hope we can still find an alternative, because there is exactly one approach that I do not want: Making things that should not be entered into the database look like tags. --Tordanik 19:50, 31 March 2014 (UTC)
Resolved: appears to be resolved from looking at pl pages Mateusz Konieczny (talk) 08:01, 14 January 2021 (UTC)

Nice work

This looks very promising and I think you’re doing a great job. A few comments:

  • The lang parameter could default to {{Langcode}}, which deduces the language from the name of the page making it usually unnecessary to set explicitly.
  • Some parameters (onNode, combination and so on) would be expected to be the same for every language a tag is documented in. Is there a was to set them for all languages?
  • Some pages use {{RelationDescription}} and its language versions. Is that to be brought into this scheme or can we revisit whether values of the type=* key actually need their own template?

--Andrew (talk) 06:42, 1 April 2014 (UTC)

Why did you add a lang parameter to each page instead of deducing the language in the template as I suggested on this page last week? --Andrew (talk) 11:50, 10 April 2014 (UTC)
Hiya - sorry, I wasn't ignoring you, although it absolutely must have looked like it…. I didn't know about {{Langcode}} before you mentioned it, and it seems to be an excellent idea - I like your plan a lot. I'm going to look at that next. When I got to trying a whole language, you're absolutely right, I could have used langcode first. In this case, I picked fi as a medium-sized language group, and looked to see how many there were with lang not specified, and found seven. I chose to edit those seven by hand and get a stage further forward, rather than implement {{Langcode}} then. But that approach is going to be too much work across all the languages, which is where your idea comes in.
Your other comments are also spot on: at the back of my mind I have some ideas of how to separate important information from individual pages, so it can be called on in different ways. If you're interested, have a look at this thing where I was experimenting with this template as a way to hold information on keys and values. There's a lot to do to get it working sensibly, but I think it's a worthwhile approach. And I'd not spotted {{RelationDescription}} until you pointed it out: it just shows that there can be really important stuff under your nose and you don't know it's there. Thanks - that looks like a great thing to incorporate.
Thanks for your valuable input and encouragement - apologies again it's taken my a while to respond. Moresby (talk) 12:51, 10 April 2014 (UTC)
Resolved: also thanks from me Mateusz Konieczny (talk) 14:24, 10 January 2021 (UTC)

New proposed KeyDescription Template

This discussion was moved from User talk:Moresby.

Hi Moresby,

I just have several questions about your new proposed templates:

  • will it work with Czech or Polish language? The reason I ask is that Czech and Polish are not really name spaces on this Wiki which complicates things a bit.
  • can you make the Group name clickable link as I have done in the current KeyDescription? Or you do not like this idea?
  • will I be able to use other TagInfo servers as I do in current Czech version of KeyDescription?

Chrabros (talk) 05:17, 7 April 2014 (UTC)

Thanks for the feedback! The implementation is not dependent on namespaces at all, so Czech and Polish shouldn't be a difficulty for this reason. There's a complication for Polish, though, as Władysław Komorek has added a "native key" functionality to the templates, which none of the other languages have. I can see arguments for and against this, the discussion has been going backwards and forwards in various places for some time, and I'm really not wanting to take one side or another - that's for others to debate. So for now, I'm leaving Polish alone. You'll see in my implementation plan that the next stage involves migrating an entire language group. I've not come to any conclusion which to choose, but Czech is certainly an option. I notice you're fluent in Czech - if you'd be happy to review the changes once they're implemented, and point out any problems, I'd be really grateful.
Yup, you're right that the group is a clickable link on current templates, and I've missed that. Apologies - I've not meant to remove any existing functionality without a very good reason, and this was an oversight. I'll get onto it.
Tordanik was very helpful in discussing external links here, where I outline how I got to where we are with just a few taginfo options. I'm determined to give people a good set of options, and he pointed me to this page which lists taginfo sites. Please make sure your favourite sites are on that list, and I'll work out how to make sure you have easy access to them. :-)
Thanks again for your comments and interest. It's really encouraging to hear from others what they think. Moresby (talk) 07:36, 7 April 2014 (UTC)
Hmm, hope that I understood correctly, that I would use your template for Czech pages and it will contain the Czech translations in itself. Or am I wrong and I would have to use your template, copy it and translate it to standalon Czech version? Chrabros (talk) 08:31, 7 April 2014 (UTC)
If I've got it right, I'll change the current Czech template to call the new one, and everything should simply drop into place, with Czech translations of the headings in the boxes, and so on. All I'll need from you is some reassurance that the language is OK in context - the rest I should be able to work out. Like any other change, it can be undone at any time, of course, so there will be nothing which is irreversible. It's just that a second opinion from a Czech native speaker will make me less worried. :-) Moresby (talk) 09:24, 7 April 2014 (UTC)
Here are current problems with your template as I see them:
  • the Czech categories are gone (I had Cs:Značky podle klíče, Cs:Značky podle hodnoty, Cs:Klíče:amenity, Czech Documentation)
  • links and descriptions of Elements Icons were Czech, they are English now ("Can be used on Node", link to Node page)
  • Tools are very wrong - I had two Taginfos (one worldwide and one for Czech Republic only) then I had another selection of some interesting countries. I think it is important for every country to choose which other countries they want to see here.
  • Overpass turbo icon is gone and it was a nice one. ;-)
  • Why is there the ugly green checkmark? File:Yes check.svg

Chrabros (talk) 03:15, 8 April 2014 (UTC)

Thank you - this is exactly the sort of feedback which I need to get this right. I assume your comments came from looking at Cs:Tag:historic=cannon.
  • I take your point about the Czech categories. Working out which categories existing templates put pages into and coming up with some sort of rationalisation was one of the biggest headaches in getting this together. You can see some of the work I did understanding this on the documentation of the {{DescriptionCategories}} template. When you attempt to consolidate forty or more divergent approaches into just one, there are going to be some differences, and what you've seen is just one of them. There's absolutely no reason that these categories shouldn't be added to Czech description pages - I'll get onto that.
  • Well spotted. These are supposed to be translated, as you can see from the template examples. For some reason I can't work out, I managed to skip Czech when I pulled all the translations into one place in Template:ElementUsageLang. Apologies - I'll fix that.
  • You can see some of the discussion about language-specific tool links here. I surveyed which taginfo sites were being used, saw that taginfo.openstreetmap.cz was linked, but that its data was only as recent as February, and crossed it off my list of active sites. I'm more than happy to put it back in, and the your comments support the views in the discussion I've just linked to that language-specific tool selection is a good way to go forward.
  • Overpass turbo is still there - it's right at the bottom, but I took out the logo, as I felt that it was too big, looked out of place and didn't match the other links.
  • If I understand you correctly, the check mark is not connected with this template, but appeared as a result of this edit of yours which included {{Tag stub}}.
Again, thanks for this: you've picked up a few things to fix, which is exactly what I'm after. Watch this space.... :-) Moresby (talk) 09:11, 8 April 2014 (UTC)
OK, I've made some changes:
  • I think that all the existing categories populated by the existing {{Cs:KeyDescription}} and {{Cs:ValueDescription}} templates will now also be provided by the new description templates. That's now implemented in {{DescriptionCategories}} - have a peek, and change the Czech section if you like.
  • There's Czech hover-text on the element usage icons now I've added it to {{ElementUsageLang}}
  • The Czech taginfo site is now on everyone's description boxes, now I've added it to {{DescriptionLinks}}. There's not too many taginfo sites yet in there to display them all on all pages, but I'll get to that in time.
Thanks again. I'm really grateful you've been able to take the time to review this for me. Moresby (talk) 12:17, 8 April 2014 (UTC)
Hi, it is getting better, but there are still some things I miss:
  • > If I understand you correctly, the check mark is not connected with this template, which included {{Tag stub}}.
Yes, I have not noticed that, but in the English version of this page the check mark is where is should be - in the stub box, but in your version it overlaps with KeyDescription box. Why? I do not know, this is beyond my wiki skills.
  • Czech Categories - OK, done, fine.
  • The +/- icon displayed in upper right corner points to nowhere in your template. In the original it allowed to edit the template itself, however I did not get the reason why it was there.
  • {{ElementUsageLang}} - I am still missing the translation of links when you click on the element icon. My versions led to Cs:Node, Cs:Way, ...
  • Overpass - well, I think that the icon was nice, but let's wait if the other will have some opinion as well
  • taginfo - I think that there will be complaints about the current implementation of this. I believe that for any language there is a specific set of taginfos which are interesting for each country. For Czech is interesting German, Austria, Slovak. For Slovaks it might be Czech, Hungarian. For Germans it would be Austria, Switzerland. For UK maybe Commonwealth countries, ... So I think that you should include the general worldwide TagInfo box as it was in the original template, including Overpass and then a country customizable selection of other taginfos (maybe initially collapsed as it was before). Just my opinion.
Chrabros (talk) 03:47, 9 April 2014 (UTC)
After a bit of experimenting, I see what you mean about the green tick. With my browser, it seems to be heavily dependent on the width of the window: if you start with a smallish browser window, and increase the width bit at a time, there's a point at which the layout changes significantly and displays the odd behaviour which you describe. I don't know what causing that, but it's almost certainly to do with CSS and layout. I'm not wanting to get into that just now, as it looks as if it's going to affect only a relatively few pages. Yes, it would be interesting to get to the bottom of it, and I expect that I will, but it's going in low on the list of priorities.
The +/- link at the top goes nowhere at the moment, but goes to the place where this template will end up when it's moved out of user space. Granted, that's not much help at the moment. The presence of links like this is related to the Wikipedia Navbar template, which includes links to view, edit or discuss the template. Perhaps it's time to be bold and change it to something more like the Wikipedia navbox links, so it's actually more useful.
I think you're right about people appreciating more taginfo links, as discussed at the links I pointed you to earlier. My main aim at this stage was simply to standardise the current forty-or-so templates, producing functionality which was broadly in line with the best aspects of each of them. There haven't been many taginfo links so far, so I've not incorporated and additional ones at this stage. These can, and I'm sure will, be added later.
The good news is that I've updated the element icons so that the link to language-specific pages if they are available. That matches what you're used to with cs, but also with pl, ja, uk and it. There are some languages where these now link to non-English pages where that wasn't the case before, such as fr, so that's a good example of taking a good idea from some templates and making it available to all languages. I think we're getting to a point where, with your help, we've got a long way with cs, and the other languages will benefit from that. Thanks. :-) Moresby (talk) 11:00, 9 April 2014 (UTC)

Resolved: it is solved, right? Mateusz Konieczny (talk) 22:31, 9 January 2021 (UTC)


This discussion was moved from User talk:Moresby.

On the page Tag:tourism=theme_park there is a problem with your ValueDescription-Template and Template:Tag stub: They are overlapping. --LordOfMaps (talk) 09:24, 17 April 2014 (UTC)

Hmmm, thanks. Weird. :-( I'll look into that. Moresby (talk) 09:40, 17 April 2014 (UTC)
OK, I finally tracked down the problem. It was a CSS rendering bug in Chrome, and I have now submitted my findings to Google. I've identified a workaround which should solve the problem. It will take a few hours for the wiki to rebuild all the affected pages, but after that there should be no more problems! Thanks. Moresby (talk) 15:18, 17 April 2014 (UTC)
Thanks! - It looks OK now.
But bug in Chrome? I had the problem using firefox. --LordOfMaps (talk) 18:18, 17 April 2014 (UTC)
Ooh, interesting. Like most bizarre happenings, it seems to have been caused by an interaction of several odd things. I boiled it down to the following, which seemed to work OK in Firefox, but not in Chrome (both on Ubuntu):
    <div style='float: right; width: 150px; border: 2px solid black;'>aaaaaaaaa</div>
    <div style="float: right; width: 250px; border: 2px solid black; clear: right;">bbbbbbbb</div>
    <div style=" text-align: right; border:2px solid blue;">cccccccc
          <img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACgAAAAoCAIAAAAD
I don't think that the content of the divs were supposed to overlap, so I put this down to a Chrome bug. That was enough to find me a workaround, which seemed like a win. It's entirely possible that I've inadvertently removed another important component of the problem in my analysis, in which case it's even more complicated than I thought. Or I just messed up somewhere along the line. Perhaps I'll try it again in Firefox to see. But I might let sleeping dogs lie.... :-) Thanks again. Oh, and thanks for picking up the German translation on some of the templates - most grateful. Moresby (talk) 18:37, 17 April 2014 (UTC)
This is definitely not a bug of Chrome, but your misunderstanding about how "float:" works in CSS: it is floating within the box of the nearest ancestor element which is positioned (with position:relative or position:absolute or float:*). In your HTML, the only box element that is positioned is the "html" element (positioned by the viewing window); the effect of "clear:*" is also relative to the same ancestor positioned box (which defines the applicable horizontal margins).
So what you get is "aaaaa" aligned to the right margin inside the html box, then "bbbbb" is displyed just below (because of clear:right), but the third element is NOT floating, and its width is then the width of its parent element (the width of body, which is itself near from the width of html): the image will then be aligned to the right, but NOT to the right margin because the floating "bbbbbb" occupies that position;
Yes the third "div" overlaps the second one, but the image in it will not overlap the content of the second div, even if the third div it is text-align:right....
In summary you must get this layout: aaaaaaa (to the right), then below it "ccccc", the icon, and "bbbbbbb"; but if on the second line not everything fits, the second line will still display "bbbbbb" and "ccccc" before it if it can fit, but the icon will wrap below on a third line (the two floatting elements will not move, they are positioned first before "ccccc" and the icon that are flowing around the two floats. Note also that the third line does not float around the two floats because of the effect of clear on the second div: clear has the effect of clearing only the right margin, but the third div is not moved down because it is still positioned by the position on the *left* margin (even if its content is text-align:right)
The only way to get three non overlapping divs float, is to embed them in a "position:relative" div, make the 3 divs as floating, and then append a 4th empty div (within the main relative div) containing "clear:both" so that the relative div will contain everything, even if the floats inside it are overflowing.
  <div style="position:relative">
    <div style="float: right; width: 150px; border: 2px solid black;">aaaaaaaaa</div>
    <div style="float: right; width: 250px; border: 2px solid black;">bbbbbbbb</div>
    <div style="float: right; text-align: right; border:2px solid blue;">cccccccc
          <img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACgAAAAoCAIAAAAD
    <div style="clear:both"/>
Note in that case that the first two divs are allowed to show side by side: bbbb must be to the left of aaaa (which is the rightmost) or below aaaa if bbbb can't fit the width in the remaining margins.
Also the third div showing ccccc and the icon can also show side by side: cccc and the icon must be to the left of bbbbb (which is more to the right) or below bbbb if cccc and the icon don't fit.
But note also that the third div does not specify a width, so its default width is still 100% and does not fit in the margins partly occupied by the two first float divs, so the whole div will wrap below the two first floats...
Floats in HTML/CSS are complex to understand the first time. You need to understand the CSS box model and the full effects of "position:", "float:" and "clear:". You also need to understand what "width" designates: it does not include the outer margins, borders, and paddings of the element (except if you use a new CSS3 property to change the "box-sizing" model, to be the "border-box" like IE6 does by default, when the default standard of HTML is the "content-box"). — Verdy_p (talk) 16:56, 26 May 2015 (UTC)

Resolved: it is solved, right? Mateusz Konieczny (talk) 22:31, 9 January 2021 (UTC)

Issue with wikidata properties

wikidata=P3863 return a error message "This entity does not exist."
Currently must use wikidata=Property:P3863 to get the wikidata property page.
See ref:ef
--Pyrog (talk) 08:19, 11 October 2019 (UTC)

Resolved: Even if it is an actual Wikidata bug, then it is still of no concern for OpenStreetMap Mateusz Konieczny (talk) 10:17, 7 January 2021 (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)

Resolved: seems solved Mateusz Konieczny (talk) 09:59, 7 January 2021 (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)
Resolved: this old redesign was replaced at least once by new redesigns

Mateusz Konieczny (talk) 21:50, 9 January 2021 (UTC)


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)

Resolved: this old redesign was replaced at least once by new redesigns

Mateusz Konieczny (talk) 21:50, 9 January 2021 (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)

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)

Resolved: Mateusz Konieczny (talk) 10:00, 7 January 2021 (UTC)


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)

Resolved: Mateusz Konieczny (talk) 10:06, 7 January 2021 (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)
Resolved: Mateusz Konieczny (talk) 10:07, 7 January 2021 (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)

Resolved: Mateusz Konieczny (talk) 10:08, 7 January 2021 (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)
Resolved: Mateusz Konieczny (talk) 21:51, 9 January 2021 (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)

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)

Resolved: Mateusz Konieczny (talk) 10:08, 7 January 2021 (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)
Resolved: (1) it was removed (2) it is not a correct place to discuss it Mateusz Konieczny (talk) 10:10, 7 January 2021 (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)

How one may hide unwanted image description

[1] 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)
Resolved: seems solved in my opinion, alt_text may be a good idea but it would be better to start a new discussion for that if someone plans to spend time on implementing it Mateusz Konieczny (talk) 10:13, 7 January 2021 (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)
Resolved: seems solved Mateusz Konieczny (talk) 09:59, 7 January 2021 (UTC)

Broken country-specific link

The country-specific forwarding from a link has been broken. Example: You are on a german page. Then all links should lead back to German pages. That worked until recently. --geozeisig (talk) 06:24, 2 October 2019 (UTC)

@Geozeisig: - Seems to be solved now Mateusz Konieczny (talk) 16:16, 19 May 2020 (UTC)

Mateusz Konieczny (talk) 21:52, 9 January 2021 (UTC)

Why Tag:waterway=riverbank has nonexisting category, apparently added by this template?

Category:Mismatched onRelation - what is supposed to be mismatched? Is it some report of broken data in the wikidata items? Category does not exists and has no description what and why adds it and how it can be fixed Mateusz Konieczny (talk) 11:13, 18 October 2019 (UTC)

Category is now documented, but user pages and template pages should not be listed there or for Category:Mismatched onArea and Category:Mismatched onNode Mateusz Konieczny (talk) 21:32, 16 January 2020 (UTC)

Mateusz Konieczny (talk) 21:52, 9 January 2021 (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)
Resolved: Translations can be fixed at Module:DescriptionFromDataItem/data--Tigerfell This user is member of the wiki team of OSM (Let's talk) 20:25, 24 January 2021 (UTC)

Proposed reuse for Machine-readable Map Feature list

There is a group working on a Machine-readable Map Feature list. In order to automatically harvest information about keys (which we call tag-defs) from the Wiki, this template should be slightly modified. —Preceding unsigned comment added by Gubaer (talkcontribs) 19:23, 21 December 2008

Proposed new arguments

  • displayName (optional): a display name for the key in the language given by lang. Will be used by interactive applications for drop-down lists, menu entries, etc.
  • onRelation (optional): whether this key can be used on relations either yes (default) or no
  • status (optional): the status of this key in it's life-cycle (similar to status in the template Template:ValueDescription). Either proposed, rejected, accepted (default) or deprecated. —Preceding unsigned comment added by Gubaer (talkcontribs) 19:32, 21 December 2008
Apparently onRelation is already present. I would also like to see a status argument, and would add it to the template, if nobody opposes. MHohmann (talk) 08:43, 16 February 2014 (UTC)

Proposed changed arguments

  • groups (optional): a comma separated list of groups this key belongs to. Groups should be declared with a new template Template:GroupRef. Example:
     groups={{GroupRef|name=naming|lang=en}}, {{GroupRef|name=non-physical|lang=en}}

—Preceding unsigned comment added by Gubaer (talkcontribs) 19:29, 21 December 2008

  • propose a solution :
    first, second ... up to 13 :) are the names of additional groups. It make list and categories for these groups. I did it in the template RU:KeyDescription --Dr&mx 20:42, 3 July 2011 (BST)

Proposed expansion of the template

The expansion of the template should include a reference to the category <lang>:Category:Keys. Example:


—Preceding unsigned comment added by Gubaer (talkcontribs) 19:40, 21 December 2008

probably [[Category:EN:Keys]] --dr&mx 20:07, 28 February 2012 (UTC)


New and changed arguments are optional. They shouldn't brake existing uses of the template. Neither does the declaration of a category.

We therefore suggest

  1. update the template
  2. adjust wiki pages (add arguments for the new parameters) step by step —Preceding unsigned comment added by Gubaer (talkcontribs) 19:40, 21 December 2008

Add a Proposal link

Hi, would it be a good idea to add a backlink to the proposal of a feature? Sometimes it is a very detailed help and gives further informations for usage, even on start of the feature --!i! 10:44, 17 August 2010 (BST)

Proposal - parameter - replaces

It might be useful to include a parameter which inidicates whether a key replaces another key; this would decrease the incidence of using "obsolete" keys. Example, see Key:power_output, which refers to Key:power_rating . . . which in turn redirects to Key:generator:output. --Ceyockey 13:17, 24 November 2010 (UTC)

well, i saw your comment by chance (actually by using "What links here") when reorganising some power keys ... sorry for destroying your example ;-) (I won't change the links here, though) -- Schusch 23:38, 24 November 2010 (UTC)

Proposal - value interpretation

I think it would be really useful if the description also included information about the scale type and the default unit of the value. This would simplify automatic conversion of values (e.g. for people who prefer inches and feet instead of cm and m).

Examples (I think that's the easiest to explain what I suggest):

key scaleType defaultUnit
width number m
voltage number V
wires count
population count inhabitants
lanes count
ele number m
include number %
maxweight number t
maxspeed number km/h
website link http://
email link mailto:
name text
highway list
amenity list
start_date date

Therefore valid scales could be 'number', 'count', 'link', 'text' (maybe we should distinguish between texts which "can" be translated like "name" and those which can't? are there any?), 'list' (for keys like highway, amenity, landuse, ...), 'date', etc.

What do you think? -- Skunk 15:36, 17 October 2011 (BST)

Clean-up/Translation out of Sync

There are even two different french templates: FR and fr
  • the "available languages" show different languages dependent on the language one choses, e.g.:
english template shows 13 languages but no German one (polish template similar)
french template shows 5 languages and exists a second time with no other languages: french
netherlands template shows no other languages (german template similar)

As a Newbie (at least regarding templates) I don't feel able doing anything to make these things clear and homogeneous --Rennhenn 15:13, 23 December 2012 (UTC)

By putting the template in those categories, you put all pages that use the template in those categories too. Since only the template itself needs cleanup, that's obviously not right. --Cartinus 18:32, 23 December 2012 (UTC)
Sorry for inconveniance, I was not aware of that - thanks for "repairing" --Rennhenn 19:52, 20 January 2013 (UTC)
All pages should have a working language bar now. German shows up as untranslated, because the language bar expects "DE" (like all the key pages themselves have), but the template has "De". If you rename the template, you have to edit all the key pages too, so I'll leave that for someone in Germany. --Cartinus 18:32, 23 December 2012 (UTC)
Thanks --Rennhenn 19:52, 20 January 2013 (UTC)

Overpass Turbo link

I don't think the recent addition of the Overpass Turbo link to the template is a good decision. Even though that site is a lot more accessible than the plain Overpass API, it is still suited for advanced users only - for others, any Overpass query IDE is necessarily confusing. But perhaps more importantly, its inclusion here is redundant because there is already a link to overpass turbo on all Taginfo pages, along with links to XAPI, JOSM, and many other statistics that are not directly linked from the infobox. So I don't see a reason to give special prominence to the Overpass Turbo link when Taginfo already neatly collects all the relevant resources. --Tordanik 18:23, 26 February 2013 (UTC)

This was initially suggested by Zuse at Talk:Overpass_turbo and added shortly after. I can see that this link shouldn't get as much prominence as taginfo for example. But, I still think there should be some room for this, too. (The wiki is not for beginners only and the link on taginfo may not be known by everyone; the way via taginfo also adds one unnecessary page load.)
After the few layout iterations, I think we have found a good solution for this now: the new "tools" section.
--Tyr (talk) 23:48, 2 March 2013 (UTC)
Danke :o) --Reneman (talk) 00:03, 3 March 2013 (UTC)

Stale links

Combinations worldwide (tagstat.hypercube.telascience.org/tagdetails.php) seems to be dead. Is this a permanent situation? If so, should we remove the link? Mmd (talk) 13:14, 23 March 2013 (UTC)

I guess it's really dead, but I'm not sure. The Tagstat page doesn't say anything about the current situation. Maybe we should simply email User:Petschge and ask. --Tordanik 20:49, 23 March 2013 (UTC)
TagStat still seem to be dead. I've removed it now. Also Tagwatch is discontinued, see[2]. I've commented out both links and added one to taginfo. The Tagwatch page does list some other useful pages. Not sure if any of those should be linked.--Salix alba (talk) 05:40, 8 March 2014 (UTC)
Good call on removing the inactive services. However, the new Taginfo link doesn't add any value because it's the same one already available in the Taginfo box. It might be more helpful to link to some of the regional versions of Taginfo instead, thus compensating for the removed regional tagwatch links. I'm not sure which ones to pick, though. --Tordanik 06:56, 8 March 2014 (UTC)
I have removed the duplicated global taginfo link and replace it (probably temporary) with links to US, UK, France and Italy (currently having problems?) versions. I would add Germany as well, but I haven't found it. Chrabros (talk) 03:32, 9 March 2014 (UTC)

Proposed seeAlso

Hi, I would like to add seeAlso to this template, same as seeAlso in ValueDescription. Sometimes it could be handy. Any objections? Chrabros (talk) 03:34, 9 March 2014 (UTC)

Proposed removal of onRelation

Hi, I would like to propose the removal of onRelation=

As it seems this icon has not really clear definition and causes a confusion.

See the discussion here Talk:Key:building#onRelation.3F.

The short summary of views is:

Which is odd as just below is a taginfo window indicating that the tag is used on relation in many cases.

  • there are really no tags which can be used only on relation. Therefore the icon onRelation is useless anyway. See relation:multilinestring.

So I am proposing to remove it.

Or maybe if someone know the definition then please write it here so we have one clear definition to use.

Chrabros (talk) 04:46, 9 March 2014 (UTC)

No matter whether we go with your opinion or mine, there are still cases where onRelation would be set to yes. So I don't see why we would want to remove it. Providing a clear definition is a good idea, but because of the recent discussion I fear the two of us will not be able to agree on one. I would be interested in other people's opinions on the topic, though.
For those who didn't follow the discussion: My point of view is that:
  • onArea=yes means that the tag can be used on areas, modelled with a single closed way or as a multipolygon
  • if a tag can only be used on areas, then use
    • onWay=no, to distinguish it from tags that can also be used on linear ways
    • onRelation=no, to distinguish it from tags that can also be used on other relations than multipolygons
--Tordanik 17:01, 9 March 2014 (UTC)
I do not see why we could not reach an agreement. The previous debate might be little bit too hot but this was partly to my mistakes while not keeping up with two separate threads. Sorry for that. I have learned that you are nice person since then. ;-)
Anyway. We could change the popup "Used on areas" to either "Used on areas (incl. multipolygon)" and similarly "Used on relations (excl. multipolygon)". And document it somewhere clearly as well. Chrabros (talk) 02:45, 10 March 2014 (UTC)
Thanks for the compliment. ;-) I fully support your suggested change. At the same time, I would suggest to point the link behind the area icon to Area. The current link target section no longer exists, and the Area page fits the icon's meaning well. --Tordanik 16:49, 13 March 2014 (UTC)
I have added links to Template:ValueDescription just now. They lead to Node,Way,Way#Closed Way,Way#Area and Relation.
It seems to me more consistent than to point to Elements for Node, Way and relation and then to Area.What do you think? Chrabros (talk) 02:53, 14 March 2014 (UTC)
I would have linked area to Area, which is called the "main article" even at your link target and is consistent with Node, Way and Relation. I also think the closed way icon is pointless, but it was not you who added it, so that's a topic for a separate discussion. --Tordanik 16:39, 15 March 2014 (UTC)
PS: Due to unrelated reasons, I've just edited ValueDescription, and as a small additional change in the same edit I've changed the area link to Area. But I want to make it clear to you that you can still give objections and change it back, I didn't intend to work around this discussion. --Tordanik 17:25, 15 March 2014 (UTC)
OK, no problem. :-) Chrabros (talk) 02:32, 16 March 2014 (UTC)

Is the group still useful?

Now Tagwatch has gone, can the group parameter go with it or is there someone else who uses it? --Andrew (talk) 14:22, 9 March 2014 (UTC)

I like Group. And I think we can make it better by adding a clickable link to the wiki page of the Group. Something like Up in the wiki structure. Clicking Group Annotation would lead do Annotations etc. What do you think? Chrabros (talk) 02:45, 10 March 2014 (UTC)
No one is protesting. I will try to change it. Maybe you will like it. Chrabros (talk) 03:49, 14 March 2014 (UTC)
I'm not necessarily opposed to this, but I think that distributing documentation across too many different pages increases the risk of duplication, contradictions and outdated pages, and also makes it hard to find what you are looking for. There are some cases where a page about a larger concept in addition to the individual Key/Tag pages makes sense, but the "Annotations" example shows that not all groups of tags are that way. Deleting the Annotations page and changing all links to Map features#Annotation wouldn't lose one bit of useful information. --Tordanik 16:31, 15 March 2014 (UTC)

I think,would be better to link group name to category. --Władysław Komorek (talk) 09:15, 14 March 2014 (UTC)

That is a nice idea. What I do not like about it tough is that category lists all tags translations as well. Don't you think that it is a little bit mess there? Also the Feature page I am linking usually has some additional explanatory text which might be handy. Chrabros (talk) 07:10, 15 March 2014 (UTC)
Category is the "gold mine" when looking for additional information. This link is better than the "See also". Category also includes the Feature page.
All translation pages should be grouped separately, as I did with "Pl" --Władysław Komorek (talk) 19:31, 15 March 2014 (UTC)
Yep, I like your categories. I am trying to do the same in Czech Documentation category. But I am a lone Czech translator so it is slooooow.
But the other translators do not care so the English categories pages are in mess.
Also there are many tags falling in two or more categories, whereas Group is just one. So it makes sense to me to have link to a Group in the box where is just one space. Links to Categories are at the bottom after all. No? Chrabros (talk) 02:36, 16 March 2014 (UTC)

native_value and native_key parameters

Transferred to Template talk:ValueDescription#native_value and native_key parameters --Władysław Komorek (talk) 15:52, 16 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)

Implemented "requires" section

Example 1:

| key         = crossing
| required=*{{Tag|highway|crossing}} or
* {{Tag|railway|crossing}}

Example 2:

|required=* {{tag|natural|grassland}}

Xxzme (talk) 16:52, 27 July 2014 (UTC)

OK! yes, please. I'm here for this exact reason. What is the usual route for changes of this template?--Jojo4u (talk) 23:19, 24 January 2015 (UTC) OK! would be helpful. --Tordanik 12:42, 28 January 2015 (UTC)

See also Request for namespace with machine-readable definitions Xxzme (talk) 04:16, 23 February 2015 (UTC)

Implemented as 'requires=', 3 Jan 2016

Resolved: Mateusz Konieczny (talk) 08:42, 21 June 2020 (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)

Resolved: Mateusz Konieczny (talk) 08:42, 21 June 2020 (UTC)

Has any real progress been made toward normalising the tag system?

I'm having a lot of trouble trying to edit just the North American part of planet.osm. As far as I can tell, the keys seem to have been selected in an ad-hoc way. There are more than 9000 unique-ish keys, which is far more than there should be even in the worst case. A lot of the information tagged shouldn't be in a mapping database because it's (a) ephemeral or (b) irrelevant to the purpose of a vanilla map. I'm not even completely sure whether "amenity" is meant to be the key, and "restaurant" the value, or "restaurant" is the key and "amenity" is just a grouping that wasn't meant to appear in the database. They're both used as keys! And that's one of the most rational bits of adhockery.

There are more than 2G lines in the chunk I'm working with, and that's clearly far more than any human being can edit by hand unless they want to make it their life's work, which I don't. But to filter it under computer control, the one who writes the filter has to understand what to keep, what to modify to make it conformant, and what to discard as irrelevant. I don't understand that yet, although Goddess knows I've tried.

--Niemand (talk) 20:39, 19 July 2017 (UTC)

You will generally get more people answearing your question if you ask on the mailing lists, forum or help forum. In general bear in mind that you can discard any tag that you are not interested in if you are processing the data set for your own use and not editing OpenStreetMap.--Andrew (talk) 22:13, 19 July 2017 (UTC)
I was hoping this was an active project. Of course, if I have to ask on the list, then that's probably my answer right there! :-\ --Niemand (talk) 22:41, 19 July 2017 (UTC)
No, there isn't really any serious effort to change old tags like amenity=restaurant at the moment. It would mean quite a lot of breaking changes to data consumers, plus changing the habits of thousands of mappers. I actually agree with you that the tagging system is unnecessarily messy, but there isn't really the kind of process or mentality in place that would allow for such a far-reaching change to be adopted. For better or worse, changes to tagging conventions happen in small, incremental steps.
When writing an application consuming OSM data, the way to deal with this is to adopt a whitelist approach: Only use correctly tagged features that are relevant to your use case, ignore everything else. So don't look at all the keys in the database and try to figure out what to do with each one. Instead, learn how the objects you need are supposed to be tagged (the wiki should usually tell you that), and only ever consume that handful of keys.
And yeah, there are more people active on the lists and forums. Asking there most likely won't give you a more satisfying answer to this particular question, but it's something to keep in mind for future questions. :) --Tordanik 14:18, 21 July 2017 (UTC)
"As far as I can tell, the keys seem to have been selected in an ad-hoc way. " - yes, you guessed correctly. In general it is
as it is offtopic on discussion page of this specific template Mateusz Konieczny (talk) 18:44, 21 May 2020 (UTC)

I suggest we sort combines values from wikibase

See https://wiki.openstreetmap.org/wiki/Key:distance_from_road for an ugly example.--PangoSE (talk) 22:22, 3 January 2020 (UTC)

agree. anyone wants to try to implement it? We have a sandbox for this template. --Yurik (talk) 22:27, 3 January 2020 (UTC)
@PangoSE: Can you give a new example of the problem? In this specific case page is gone due to other, mostly unrelated, issues Mateusz Konieczny (talk) 18:42, 21 May 2020 (UTC)
@Mateusz Konieczny: no, I will comment here if I find another example.--PangoSE (talk) 09:48, 25 May 2020 (UTC)
Resolved: seems to not be a problem anymore Mateusz Konieczny (talk) 08:49, 29 October 2020 (UTC)

Proposal "appliesTo"

Every key applies to some features. I propose to add a new parameter "appliesTo" analog "seeAlso". --Rudolf (talk) 08:06, 3 June 2014 (UTC)

AFAIK the parameter "combination" is used in a similar way. Could you elaborate further on how this parameter would work? For example, how would this parameter look on the template in the page Key:capacity ? Would it be used on pages like Tag:highway=steps ? --Jgpacker (talk) 19:08, 3 June 2014 (UTC)

Resolved: closing as outdated and replaced by other parameters present nowadays Mateusz Konieczny (talk) 21:44, 9 January 2021 (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)
Resolved: Fixed as desribed --Tigerfell This user is member of the wiki team of OSM (Let's talk) 15:19, 26 January 2021 (UTC)