Template talk:Description/Archive 1

Translating an existing page

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

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

Why don't we put the "Other Languages" table into another template (allowing parameter 1 to overwrite the title), so that all the different templates use the same block? It could be used 1.) in other languages and 2.) on other templates… -- MapFlea 15:36, 12 November 2008 (UTC)

Yes, I also think it would be better to have a generic Template:Language! And like in Template:Language-mp (which should also be replaced) there should be no ifexist-tests. Whenever a translation-page exists can be seen by the color of the link. Parameters are not needed as we can use the {{PAGENAME}} variable. See mediawiki:Help:Magic_words --Phobie 15:58, 13 November 2008 (UTC)

Resolved: archived --Chris2map (talk) 08:07, 15 April 2023 (UTC)

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):

To {{Description}}:

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.

To {{KeyDescription}}:

1. Low-value fiddling.

To {{ValueDescription}}:

1. Low-value fiddling.

To {{RelationDescription}}:

1. Hurried workround to changes to {{Description}}.

To {{DescriptionLang}}:

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).

To {{StatusLang}}:

1. Ordering by string instead of language (need to consult translators whether good).
2. Updated translations to French and Czech (to be kept).

To {{ElementUsageLang}}:

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):

To {{Description/doc}}:

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).

To {{KeyDescription/doc}}:

1. Tidying of documentation and additional explanations (to be kept).
2. Addition of editing warning (to be kept).

To {{ValueDescription/doc}}:

1. Addition of editing warning (to be kept).
2. Adjustment of wiki syntax (to be kept).

To {{RelationDescription/doc}}:

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)

Rendering

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: data updates #10 ^GitHub --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)

Problem(s)

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):

<html>
  <body>
    <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
                                          nC86AAAAAXNSR0IArs4c6QAAAC9JREFUWMPtzQEN
                                          AAAIAyC1f7SHMoabgwJ0krowdUQsFovFYrFYLBaL
                                          xWKxWPwxXjfQArS/bUCpAAAAAElFTkSuQmCC"/>
    </div>
  </body>
</html>

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.

<html>
 <body>
  <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
                                          nC86AAAAAXNSR0IArs4c6QAAAC9JREFUWMPtzQEN
                                          AAAIAyC1f7SHMoabgwJ0krowdUQsFovFYrFYLBaL
                                          xWKxWPwxXjfQArS/bUCpAAAAAElFTkSuQmCC"/>
    </div>
    <div style="clear:both"/>
  </div>
 </body>
</html>

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)

Is it affecting OSM Wiki or OSM in any way? Mateusz Konieczny (talk) 08:40, 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)

Template:Lang:ValueDescription

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

lang=de (and all others, too?) still does not work! --miloscia 18:27, 11 August 2013 (UTC)

That's unsurprising because, although the parameter is documented, there is no translation mechanism in this template (except some code in the automatically embedded Languages bar). Pages typically use templates such as Template:DE:ValueDescription. --Tordanik 10:21, 12 August 2013 (UTC)

Then there are 2 possibilities: Either, the "lang" parameter is removed from the documentation page and instad, the user is told to use the referred language templates. Or this template is changed in order to enable a language switch (which should not be too difficult using the "switch" function). What is preferred? --miloscia 13:40, 12 August 2013 (UTC)

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

better to make one offer universal analog template for any other templates such as KeyDescription, ValueDescription and other --dr&mx (talk) 18:46, 15 August 2013 (UTC)

I'm sorry, I do not really understand your comment. I moved the "translation template" to Template:DescriptionLang, and of course it can be used in Template:KeyDescription as well. --miloscia 12:19, 16 August 2013 (UTC)

The "tagstat" or "tools for this tag" seems a little different in each language template. Using one single template structure makes it easier to manage that, i.e., make it comparable for all languages. In the long run, all templates like Template:DE:ValueDescription can be deleted. miloscia 12:43, 16 August 2013 (UTC)

Could you give a reason why you prefer that possibility? Although I think it would be acceptable, it should be noted that currently most of the Tag:* pages use the first option (i.e. separate templates for each language), so my default reaction would be to stick with it unless there are good reasons to switch. It's also not just a simple matter of translation because the content is somewhat different, and at least in some cases that is intentional. For example, the German version has tool links for Germany, Austria and Switzerland (the largest German-speaking countries), whereas the English one has continent-wide statistics due to its global role. --Tordanik 12:50, 16 August 2013 (UTC)

Well, to me it just seemed that possibility is easier and more clear and thus changes can be implemented directly, whereas now you have to compare each language template, which is a little different. Therefore, language templates which were created by copy&paste (and translating a few words) seemed "unnecessary" for me - Keep it short and simple.

I'm rather new here, but I've been working in several Wikimedia projects (which is why I'm familiar to the template structures and programming). Having the tool links in mind, separare templates would - of course - be acceptable for me, too - if maintained consequently. (However, using a "switch" for the tool sections suitable for the corresponding country would be possible aswell.) --miloscia 07:22, 17 August 2013 (UTC)

You can program Mediawiki within the template so that it displays statistics for a different selection of countries as easily as you can display messages in different languages. The existence of the #switch statement is a clear sign that the different links are intentional (for instance someone might simply copy and paste updated tool URLs in cases of linkrot without even noticing the difference) and oddities such as the second language box in Template:DE:RelationDescription can be justified or removed. Andrew (talk) 14:14, 18 August 2013 (UTC)

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: --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)

Rendering

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

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

Edits since January 2015, consider reversion

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

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

(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

(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 Nospam. 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 (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)

Resolved

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)

Resolved

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 (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 (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

(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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 19:29, 21 December 2008

propose a solution :
```
 |groups={{GroupList|en|first|second|e.t.c.}} 
```
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)

Google definition: Perhaps use Wikipedia, instead of Google? —Preceding unsigned comment added by Acrosscanadatrails (talk • contribs) 13:12, 3 February 2009

Proposed expansion of the template

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


   [[Category:en:Keys]]

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

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

Transition

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

update the template
adjust wiki pages (add arguments for the new parameters) step by step —Preceding unsigned comment added by Gubaer (talk • contribs) 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

the templates in the different languages are different, e.g. english, german, netherlands, portuguese

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:

if the tag is used on Area then it could be used on relation:multipolygon and therefore it is onRelation=yes
onRelation=yes should be used ONLY for tags suitable/designed for relations (boundary=*,route=*,..). It should not be set just because of relation:multipolygon.

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:

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

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

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) 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

Resolved

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 (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

(Let's talk) 10:24, 13 April 2019 (UTC)

Resolved: Fixed as desribed --Tigerfell

(Let's talk) 15:19, 26 January 2021 (UTC)

Changes

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

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

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

Any thoughts/objections?

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

I agree with removing definition and especially discussion links. The definitions aren't necessarily helpful -- the relevant definition is the one given by the page itself, not by some external sources. If external links (e.g. to Wikipedia) are useful, they are commonly provided anyway (using the [[wikipedia:foo]] syntax). Using the icons as links to element pages is probably a good idea, too.

I don't agree wih including tagwatch information in the box, especially if it would require page updates to keep the info up to date. You couldn't put all the information from tagwatch in that box anyway, and a single click really isn't too much effort.

I also don't agree with "Often used in combination with", because I believe that this section shouldn't simply be based on usage statistics (again, we have Tagwatch for that), but on the page authors' human intelligence.

Btw, could you please apply the changes you made so far to Template:KeyDescription, too? --Tordanik 11:56, 23 February 2009 (UTC)

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

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

Link to "other language discussion sections"

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

This proposal may make sense but is completely unrelated to this template Mateusz Konieczny (talk) 11:27, 25 January 2021 (UTC)

Resolved: misplaced Mateusz Konieczny (talk) 11:27, 25 January 2021 (UTC)

status=inuse vs status=defacto

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

The documentation now states:

"in use" - "the feature is in use"

"de facto" - "Status indicating the tag is in widespread use, but no formal proposal process has taken place."

So the status "in use" can be added for any tag that is currently being used. I generally limit this to tag used by more than one mapper, and more than 100 uses for most features (unless it is a feature that is only expected to be seen less than few hundred or few thousand times in the world, eg place=sea), and use a different status for a tag that has only been used a couple of dozen times, or by one mapper / one import only.

The status "de facto" should be limited to tags that have been accepted by the community, show by common use by a large number of mappers in many different countries. Most of these tags have been used many thousands or millions of times, for a number of years, and most should be on the Map Features page already. --Jeisenbe (talk) 23:44, 7 July 2019 (UTC)

Resolved: it is now documented Mateusz Konieczny (talk) 11:27, 25 January 2021 (UTC)

The order of Implies and Useful combination

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

No, i think it should not be changed. --Reneman (talk) 19:14, 5 February 2016 (UTC)

No, since you have to consider the order of 'requires', 'implies' and 'combination'. The first two have more formal character and should stay together, and their added importance is higher than useful combination. --Polarbear w (talk) 22:57, 5 February 2016 (UTC)

I have the same opinion as you Polarbear. The "Implies" says that combinations using the same implied tags may just be redundant and that we don't need them (unless there are some unknown cases to document where the implication should be moderated). "Implies" means that if this is false, we need discussions and changing these implications will require modifying tools using these data under those (limited) implicit preconditions.

In all other cases, there's an infinite number of possible combinations, and we just list a few of the most frequently used ones (for which it will be convenient to implement some presets in editors), but none of these combinations are implied and they are extensible.

"Implies" must be documented (generally this is because the tag is used to add some detailed semantics to another more generic tag, i.e the current tag is part of a derived subclass of the base class represented by the "implied" tags). "Useful combination" is not really necessary in tag descriptions, they will be used in derived subclasses of the class for the current tag, and those derived subclasses will be documenting their tag with an "implies" section linking to the current tag: in all object models, it's essential to document the parent classes as exhaustively as possible, but not all derived classes. — Verdy_p ^(talk) 11:38, 30 April 2016 (UTC)

Resolved: no consensus for change, noone shared support for change Mateusz Konieczny (talk) 11:26, 25 January 2021 (UTC)

default status should be draft or empty

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

@Polarbear w: could you link to the page where you saw this? Thanks! --Yurik (talk) 04:04, 5 February 2019 (UTC)

Hard to reproduce. It was on this version of the page. But last night yurikbot copied the now set status into Q5893 which applies to the old version also. So I tried to set up a [[3]] which plausibly shows 'unspecified'. But the test page has no item behind.

See Tag:building=sports_centre, has no status= but looks like "approved". --Hufkratzer (talk) 14:26, 5 February 2019 (UTC)

Thanks @Polarbear w: & @Hufkratzer:, turns out this was actually by design. building=sports_centre (Q6641) has no status (P6) value, but the "fallback" entity for the key itself - building (Q108) has its status set to approved. I could disable falling back for statuses, but than why set the status on a key? Unless of course we want to have a strict separation between "enum-like" keys and the "non-enum" keys. For example, enum-like "building" or "religion" keys have a semi-well known list of allowed values - and each value must have its own status. The "non-enum" like "address" would have no statuses on the values? In the mean time, I will disable fallback for the statuses. Thoughts? --Yurik (talk) 16:29, 5 February 2019 (UTC)

Too late tonight to think about the handling of non-vs-enum keys. The building page now shows 'unspecified' which seems the most logic for an unspecified status. --Polarbear w (talk) 00:26, 6 February 2019 (UTC)

Seems to be fixed now? Mateusz Konieczny (talk) 18:11, 24 January 2021 (UTC)

Resolved: Mateusz Konieczny (talk) 11:25, 25 January 2021 (UTC)

Name is not required but useful.

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

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

Same explanation as above: Yurik's bot has copied it from Pl:Tag:amenity=bar to Item:Q4892 (here) and now the template displays it in all wiki pages. I don't like this confusing system at all. IMO the template should only display what is on the wiki page itself and additionally hints if this conflicts with other wiki pages. --Hufkratzer (talk) 12:06, 13 April 2019 (UTC)

I also would prefer to avoid such data leaks and display only what is on the wiki page itself. Mateusz Konieczny (talk) 18:04, 15 April 2019 (UTC)

I edited item at https://wiki.openstreetmap.org/w/index.php?title=Item:Q4892&diff=prev&oldid=1842733 - but for now it is still displayed. Maybe it will disappear soon, but I am not happy about that misleading information that requires editing completely unrelated page to fix it. Mateusz Konieczny (talk) 18:08, 15 April 2019 (UTC)

Resolved: this specific case is solved, removal of data item leaks would require larger discussion Mateusz Konieczny (talk) 11:24, 25 January 2021 (UTC)

status=depreciated

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

Added all of the missing values to the English documentation. There is deprecated already. --Tigerfell

(Let's talk) 09:18, 30 May 2019 (UTC)

The status deprecated is in the documentation, does it need more?--Andrew (talk) 09:38, 30 May 2019 (UTC)

Resolved: deprecated status is already available Mateusz Konieczny (talk) 16:30, 24 January 2021 (UTC)

Parameter "image_caption" purpose? is working?

The feature description of parameter "image_caption" says: "the description of the image to be used to illustrate the feature (optional)". Does that mean when moving the mouse pointer over the image (picture) then there should be displayed a description text? If so, then this function seems currently not working. Example page for testing is: https://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dpath Or is it not working anymore, because of the implementation of the new dataitem-module: https://wiki.openstreetmap.org/wiki/Module:DescriptionFromDataItem ? --MalgiK (talk) 13:34, 19 May 2020 (UTC)

I remember that it was some time ago it was appearing under image (as a text) it way that made image small and not readable. Also, it was often pulled from data items and resulted in adding text that was often completely pointless. Alt text visible when mouse hovers over image or used by screen readers seems fine. I would be OK with text added in way not reducing readability of image - as long as it is used solely in rare cases where it is necessary. Mateusz Konieczny (talk) 16:04, 19 May 2020 (UTC)

I seem to remember Tag:highway=motorway getting pointless description "Αυτοκινητόδρομος" from https://wiki.openstreetmap.org/wiki/Item:Q4980 - such bugs must be avoided Mateusz Konieczny (talk) 16:15, 19 May 2020 (UTC)

This parameter is now removed from template and its documentation Mateusz Konieczny (talk) 18:09, 24 January 2021 (UTC)

Resolved: Mateusz Konieczny (talk) 11:28, 25 January 2021 (UTC)

Using structured data items

I wrote a modified version of this template that can also pull data from the corresponding Wikibase item. This should allow us to consolidate all data about a key in one place, make it easier to edit (e.g. adding a translation would not require creating a wiki page, copying templates, etc), and let 3rd party devs use the data directly. I am not yet sure how we should highlight when the template's parameter is different from the wikibase item - it adds to several tracking categories, and also draws both descriptions, one in red. TBD. --Yurik (talk) 06:30, 28 September 2018 (UTC)

Resolved: implemented, exists for some time Mateusz Konieczny (talk) 16:20, 24 January 2021 (UTC)

Categorisation Change

I changed

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

to

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

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

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

Resolved: seems safe to archive after such long time Mateusz Konieczny (talk) 12:34, 26 March 2021 (UTC)

Language-specific tool links

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

Thanks. :-) I really think this could make a difference. Yes, when I started, I thought that per-language support for external links would be a sensible thing. But when I analysed which external links the various templates provided, there was some language-based variation, but almost exclusively to sites which no longer functioned. Here's an analysis of which sites are linked to across the entire set of templates:

Website	occurrences	site status
http://tagwatch.stoecker.eu/	356	redirects to taginfo.openstreetmap.org
http://tagstat.hypercube.telascience.org/	32	site no longer active
http://overpass-turbo.eu/	15	active site
http://taginfo.openstreetmap.us/	6	active site, but data almost a year old
http://taginfo.openstreetmap.org.uk/	5	active site with recent data
http://taginfo.openstreetmap.fr/	5	active site with recent data
http://taginfo.hanskalabs.net/	5	server error
http://taginfo.openstreetmap.org/	3	active site with recent data
http://osmdoc.com/	3	domain parked
http://taginfo.openstreetmap.cz/	2	active site
http://www.google.com/	1	well, it's Google

So, that left only three or four active sites, and I managed to squeeze them quite happily into the bottom of the box, via the {{DescriptionLinks}} template, which I seem to have missed in the tree above - sorry, I'll fix that. The template is passed the language of the description box, so it could, as was originally the idea, provide links which are specific to that language/locale. But it's not at the moment, as there aren't any to provide… If/when there's call for it, I (or someone else) can add this in, but at the moment everyone gets the same external links. For now, that's probably quite a good thing, perhaps. Moresby (talk) 22:13, 31 March 2014 (UTC)

The obvious canditates would be the local taginfo instances. Right now it's just UK/US/FR for everyone, but the several sites on openstreetmap.ru seem pretty much alive, It's not something that has to be done right now, of course. But it's good to know that we will be able to provide a bit more variation eventually. --Tordanik 23:24, 31 March 2014 (UTC)

OK, breaking news: have a look here. Each user can now configure which country sites he/she wants in addition or instead of the default set. I'm working on being able to set a different default set for descriptions of a given language, but that's not there yet. Do let me know what you think.... Moresby (talk) 13:26, 12 April 2014 (UTC)

Done now. Each language has its own set of taginfo links. I've made a stab at putting the mapping together here but I'm sure it could do with specialist knowledge. Moresby (talk) 16:31, 12 April 2014 (UTC)

Resolved: Seems to be solved and/or outdated Mateusz Konieczny (talk) 11:31, 25 January 2021 (UTC)

Categorization and capitalization of group

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

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

It has started with low<ercase almost everywhere, except in placers where there were unexpected duplication. For now it is indepenant of how if is displayed in the box (using generated capitals), but there's no way to reverse the capitalization for maing categories. For now these categories by group are still experimental, but not widely disployed (Tag descriptions for group "<groupname>") when in fact I think it should just be "<Groupname>" in most cases. Note that when both are existing, tag description pages will be categorized in both. Nothing happens for sorting pages by group if neither one of these two subcats have been first created (this still works as an experimentation but groups (and subgroups) is still not very well organized and experimetnation continues with them. We are not required to set groups for every tag description page or every key page, they only exist where there's some reasonnable reason for grouping several related topics. — Verdy_p ^(talk) 22:17, 12 March 2017 (UTC)

I would like to clearly state that I would like to use the categories by group and I can not because Verdy_p insists on having the categories' names in lowercase but users enter the group= parameter almost consistently in TagDescription and KeyDescription with first capital letter. The result is that we have many categories pre-created with names in lower case but with no contents. I would like to fix that. Please someone choose either Group or group and automatically convert the case of created groups in this template. Thank you vey much in advance. Chrabros (talk) 00:24, 13 March 2017 (UTC)

You are only wanting to make an unilateral change that would affect MANY MANY pages that have been created with these lowercase letters (not jsut by me but long before, when groups where first introduced.

Once again you don't understand that your change will require much more work. The few pages that used capitals there were created as errors, creating a few duplicate categories.

And writing parameter values from the group name with their normal orthography, is absolutely NOT blocking you to use these groups! Many groupos already exist since long and are filled this way.

This does not change the fact that the pages in questions have consistently used since the begining the initial NOT uppercased, even if the infobox just displays them with a leading capital.

This also does not affect how categories where the group name is used in isolation are still using a leading capital (like all other categories or pages, not just group).

Really look at these existing categories (note that categories by group are not used for all tag or description pages, and there's a lot more work to do; but all the important groups used by the most frequent tags have used lowercase group names in their categories since ever (notably because this was frequently the same lowercase value used in OSM tag keys or in OSM tag values) !

You are only confused by what the infobox displays on description pages themselves: the capitalization of the parameter is made only there.

And if you think it is simple, you seem to ignore the requirements of different languages (those written in bicameral scripts) about capitalisation (notably English, French, German and Georgian have very different rules).

Note: the categories in Category:Key descriptions by group are much more populated for now than those in Category:Tag descriptions by group (they use the same naming scheme).

— Verdy_p ^(talk) 05:43, 13 March 2017 (UTC)

Note also that this is documented since long this way in templates generating the infoboxes. Read the doc ! You were not there 3 years ago (first by Moresby) when all this started to be implemented and a cleanup project started that decided all this trying to unify many more inconsistant naming schemes. Groups were then added and tested, then started to be used slowly, but consistently (until recently) when these categories started being used (and the first ones created were using the same value as important key names (lowercased). — Verdy_p ^(talk) 06:02, 13 March 2017 (UTC)

Final note: it's much simpler to edit tag description pages than changing names of categories. Only a small fraction of all tag pages or key page names still use this parameter. But everything was documented with examples. — Verdy_p ^(talk) 06:10, 13 March 2017 (UTC)

Where in the documentation of {{Description}} stands that group name should be case sensitive? I cannot find it. Chrabros (talk) 09:40, 13 March 2017 (UTC)

PS: Yes, I was here when this change of templates was implemented. Chrabros (talk) 09:42, 13 March 2017 (UTC)

So I did my little math. There are 12244 tag/key pages, out of them 5055 has a group filled in. And quess what 895 of them start with lower case letter and 4109 start with upper case.

So you are suggesting that we fix 4109 pages, instead of few categories, because you do not want to acknowledge that you have made a mistake when initially creating it. Nice. Chrabros (talk) 11:10, 13 March 2017 (UTC)

I don't lie, read the example above which was the inital one. The later example was added much later, without checking the result, and it was wrong for this issue. Since the begining the categories have all been created with lowercase (and not by me), and used as documented since the start. I participanted to the initial template but did not choose and did not change the naming convention that was already there.

Please don't select only one thing in pages without loosing the hitory and ignoring the rest of the page. And don't use harassing abusing words like you did here again. — Verdy_p ^(talk) 12:51, 13 March 2017 (UTC)

OK. Let's just say that changing the documentation during a discussion about it is not nice.

But there is the documentation you are constantly refering to? This one example of group=shop and the second with group=Historic?

As I can see the second example was added on 18. 4. 2014 by Moresby himself. This is same day this template was rolled out. Again dubious information given by you.

Anyway I have not found any documentation stating that the group parameter ought to be case sensitive and that for those categories it is required to be lower case. Where is it?

And the most important question: How do you propose to amend this situation?

Chrabros (talk) 13:57, 13 March 2017 (UTC)

The documentation was correct and not changed, the first examples given were correct and not changed, only the last example added later was incoherent.

The code was not changed to force a change of lettercase (this will be even worse than fixing pages (it's much more complicate to change the category naming as it requires editing them multiple times, as well as editing all member pages as well. — Verdy_p ^(talk) 14:58, 14 March 2017 (UTC)

OK I read your answer like this: It was never documented anywhere that the categories are case sensistive and that we want them lowercase in English, except for this one example.

So what do you propose to do now to populate the categories? Chrabros (talk) 02:04, 15 March 2017 (UTC)

If you look at all these categoies, they are already using lowercase since long, using group names but not in isolation. When groups where first introduced there were several schemes proposed, and unification with several tests was still not tested. But then it became possible to use BOTH categories with group names used in isolation (i.e. Category:group) for common topics (many of them already existing, but where the initial is normally not case sensitive except after a language name prefix, so for this case only the initial is forced to uppercase to allow interlingual navigation), and as part of the name (i.e. Category:Tag description for group "group" or Category:Key description for group "group") where case is always significant (so forcing case is not enforced there).

Still when this was created 3 years ago, groups were still experimental, then more or less well added to Key/Tag pages without seeing what was their effect (notably because this was still experimental, pages were added to these categories ONLY if these categories were existing). Nobody noticed, when they added groups, that one of the two categories (named in isolation, or in a longer name) was fed. The initial tests were ONLY using lowercase.

The error came later because many pages were modified to add group names without seeing if it had the intended effect: all these edits were wrong. But it's simple to fix them (even if there are about 5000 Tag/Key pages, it does not require extensive edits, and it's much simpler than having to recreate thousands of categories, plus editing all member pages, and creating the redirecting categories for navigation; and not all languages are concerned by these changes, notably there's no need to edit the Japanese pages that already use translated group names, but with category redirects for their matchiung category in English: here again we should avoid having to handle thousands of new category redirects, notably now that updates in categories or changes of categories in pages are extremely slow since the recent upgrade of MediaWiki version on this server: the job queue has been slowed down dramatically).

We are reaching a point where the initial experimention on using groups starts being wanted. We can fix the 5000 pages created without testing them. It won't affect the navigation, and no new categoy redirects are needed.

Not also that not all languages are using categoies by group: this is disabled by default, and only enabled in a few languages where category names have been tuned.

I still maintain that the intent since the begining was to have group names in English being lowercase, just to match also the key names or value names used in OSM tags. But group names are still translatable: they are not necessarily in British English. We won't change how OSM tags are named themselves, and external tools depending on them to find their doc will remain as is.

Groups are completely underdeveloped, and still need structuration (there are cases where duplicate group names also exist with singular or plural in English, when other languages do not have such distinction, notably Asian languages). Ideally some tags could belong simultanesouly to several groups (but for now only one is supported: other groups are only added by adding categories in pages themselves, or adding links in descriptions).

Forcing existing pages in the description templates to force lowercase will have impact. We could do that, but with a test that will detect when this changes the effective full page names we want to link to: I would suggest just adding a tracking category and then look at it to see what is detected. It will take lot of time to be reflected. But at least we will be able to cleanup the situation progressively without having to make massive changes without measuring their effect and having the possibility to revert them. I don't like the idea of using "lcfirst:" it does not work correctly in various languages (and notably not in German). Only "ucfirst:" is safe, provided this is the initial word in page names (and here it is not the case).

Then you say "it was not documented", well it was documented indirectly in the first correct example (with group=shop) but incorrect in the last example (with group=Historic). About the "historic" group it is already fixed. the example is also fixed. So there only remains the Key/Tag pages added later that have used incorrect values (with noone detecting it, not even those that added these groups without reviewing them).

I suggest then to just detect in *English-only* Tag/Key pags names using the template with a group name with an initial capital (where lcfirst:group and group will be different) and track these pages in a maintenance category. But not changing the categories that will be looked for. A single tracking category will be enough. Then their translated pages will just have to update the same fixed group name as English (if needed: not needed in Japanese for example where almost all group names are already translated). A few new categories were added recently for Spanish using the same capitalization as English, but there's not a lot of them). — Verdy_p ^(talk) 03:32, 15 March 2017 (UTC)

I still don't understand where this recreate thousands of categories comes from. Thousands? I see 8 categories in Category:Tag descriptions by group (not counting Japanese as I doubt they have capital letters) and 71 categories Category:Key descriptions by group. It is not that complicated. Chrabros (talk) 05:07, 15 March 2017 (UTC)

You forget Category:Key descriptions by group also impacted and their translations and their redirects when translated (including redirects for Japanese). Well it's not thousands, but still complicate.

There's no emergency to create new groups, there's other cleanup to do first (including merging duplicates and making sure that groups are correctly organized), for now most groups have just been randomly created without thinking about what would fit in them. We can cleanup this. But even before the (still experimental groups) there's priority for other tasks listed since long in this page. Groups were unfoirtunately added when basic cleanup listed above was still far from being finished. For now these groups are accessory and work only for a few ones where there are related contents also outside Tag/Key pages. — Verdy_p ^(talk) 14:06, 15 March 2017 (UTC)

As we cannot reach any consensus I have summarized the problem and its solution from my point of view and called for others to state their opinions. Hopefully we can settle on something. The proposal is here: Talk:Wiki#Proposal_for_creating_group_categories. Thanks. Chrabros (talk) 04:28, 16 March 2017 (UTC)

Well, it seems that no one has shown any interest in this problem for a week which I find little bit sad.

As we are not able to reach any consensus about group naming in English I think nothing will happen for some time. However there is a consensus for Czech naming of groups. We would like to have them with first letter auto capitalized. Are you able and willing to implement this change for us? You have definitely more experience with those templates than I do. I am affraid that if I will try to do it it would be painful for me and for the wiki as well. Thanks. Chrabros (talk) 23:03, 21 March 2017 (UTC)

(Unindenting below).— Verdy_p ^(talk) 00:00, 22 March 2017 (UTC)

Of course I can supply this capitalization for Czech if this is the consensus. But you'll have to change various categories (note thaty editing tag/key pagers for changing the capitalisation of status=* values has no effect, as these values are only specified in English and the letter case of these English values is always ignored to find categories and translate what is displayed in the navbox, or the name of translated categories; the actual capitalization being part of the templates performing the translations: it is quite easy to do for these status values, that are fully enumerated, but not so evident for groups that form an always growing and open set that will need to evolve over time).

As you request it for Czech, I could do that only for Czech (but not for English) and the problem is that you xanted that for English too and have even needlessly started to change case in English group names without looking at the many existing categories that depended on lettercase and need to have translated categories linked together from the same English base name for the {{Languages|Category:name of relevant category for "groupname"}}. It's not simpel to change English without a larger consensus and lot of work. But as groups are still very unstructured and more or less "flat" (and will very likely changed in many Tag/Key pages to structure them and associate them to existing relevant features), I think it's still overkill to change these names for now.

Note that ll your Czech categories are already using lowercase (using untranslated group names!):

e.g. Category:Cs:Popisy klíčů skupiny "historic" which should be linked to the parent category Category:Cs:Historic (also not translated here, but correctly translated in Japanese, French, Spanish...)
e.g. Category:Cs:Popisy klíčů skupiny "tourism" which should be linked to the parent category Category:Cs:Tourism (same remark, correctly transalted in German, French and Spanish)

Do you see the problem? Groups are still in very alphas stage, not fully setup in English, so their translation is still extremely optional. We should not have to maintain categories fro names that are missing also in lot of places or were not coherently chosen (and it's not jus a question of capitalization, but more importanyly a problem of relevance for terms).

You'll also see that when pages are categorized in Category:Cs:Popisy klíčů skupiny "historic", they should no longer be categorized in Category:Historic or its translations, but the relations between the two are still not established, and it was still enver decided to make such moves, because groups are still very experimental. In other cases, groups only exist in isolation and in most languages there's no such category similar to Category:Cs:Popisy klíčů skupiny "historic", because precisely tags/keys per groups are disabled by default but they are categorized directly in Category:Historic or its translations.

Given the huge cost in maintenance of categories, I think it is strill much simpler to maintain only separate pages that will populate only a few categories that have been requested and not disabled by the current default naming scheme. Just write them in lowercase in group=* parameters of navboxes (like for status=*) and there's nothing more to do. — Verdy_p ^(talk) 23:58, 21 March 2017 (UTC)

Yes, we need some consensus. But it seems that no one else cares. So please try to auto-capitalize the category name for those Czech groups and I will rename then those two existing categories to Category:Cs:Popisy klíčů skupiny "Historic" and Category:Cs:Popisy klíčů skupiny "Tourism". Thanks. Chrabros (talk) 01:04, 22 March 2017 (UTC)

Well, I have renamed the categories, but the tags and keys still point to the old lower case ones. With the exception of tags/keys I have edited afterwards. Do you know if there is some robot which would re-categorize all those tags/keys in the background some day? Or it it categorizes only while saving som changes? Chrabros (talk) 23:58, 22 March 2017 (UTC)

OK, while examining it further it seems that there is some bot, because some keys were re-categorized without editing. However it is very strange if you have a look at

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

As I said you will still need to reference the unchanged English name for categories. I have not changed the English categories at all (and not any other languageà. So keep lowercase in the parameter for the Languages template used in the Czech categories. I had warned you multiple times about that : all other languages are still linking the Czech pages from the unchanged English category name! — Verdy_p ^(talk) 00:34, 23 March 2017 (UTC)

Note: there's NO bot running. But categories are indexed by background jobs (and we depend on the speed of the job queue handler, which is much slower now compared to before the recent upgrade of MediaWiki. So there are delays to see any page being visible in the new category when a page (or transcluded templates) are modified. Even performing a null-edit (edit/save without change) no longer accelerate the reindexing job if the page is already queued. You will need to wait until the job queue advances: the change being already queued, it will happen but withoiut any guaranteed delay. See statistics about job queue with the MediaWiki API (because it's no longer visible in the Special:Statistics page since long!) You'll find an API link in the Servers status page (linked from the home page): it gives the current job queue length in a JSON, just formatted for HTML when viewing it from a browser. Note that sometimes the job queu can be extremely long and will stall, constantly growing for days (sometimes several weeks...) if a job is extremely expensive (this happens notably after any MediaWiki verrsion upgrade on the server when it is busy recreating new indexes: this wiki server is much less powerfull than Wikipedia or Commons where the job queue is operated by multiple concurrent servers and with a high level of parallelism of database servers. This wiki does not run in a large farm with many servers like in Wikimedia. — Verdy_p ^(talk) 00:44, 23 March 2017 (UTC)

Why should I keep lowercase group in the Czech template Description? I do not understand it. There should be no relation to English categories in Czech tag/key description page. Or is it? Where?

Anyway it seems to work for recently edited pages with both group=Náboženství and group=náboženství. See here: Category:Cs:Popisy značek skupiny "Náboženství".

So I do not understand why you instist that I should use group= with lower case in Czech pages. It should be autocapitalized now. Chrabros (talk) 01:05, 23 March 2017 (UTC)

I only inist for now on keeping thing unchanged on English for now, because it affects all languages, and because, as you've seen, changes in category names are not immediately visible and renaming them is not so easy (and anyway these categories are still experimental and were not seriously discussed and structured correctly, they are enabled only in a few languages and disabled by default in all others). — Verdy_p ^(talk) 13:00, 23 March 2017 (UTC)

@Chrabros: do you still think that it should be changed? Mateusz Konieczny (talk) 11:35, 25 January 2021 (UTC)

openstreetmap-carto rendering: unknown versus not rendered

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

osmcarto-rendering = versus osmcarto-rendering = NotRendered?

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

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

This would provide valuable information:

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

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

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

Resolved: In this case Verdy_p makes good point that was not answered for over 3 years Mateusz Konieczny (talk) 11:35, 25 January 2021 (UTC)

Add alt-text for small images?

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

I wholeheartedly agree that there should be alt text for these images, but ... isn't that already the case? Here's some snippets from the HTML of Key:highway:

<img alt="Edit or translate this description." src="https://upload.wikimedia.org/wikipedia/commons/thumb/6/63/Arbcom_ru_editing.svg/12px-Arbcom_ru_editing.svg.png"

<a href="/wiki/Node" title="may be used on nodes"><img alt="may be used on nodes" src="/w/images/thumb/7/76/Osm_element_node.svg/30px-Osm_element_node.svg.png" width="30" height="30"

--Tordanik 19:53, 9 August 2019 (UTC)

Ugh, you are right, it's a problem / feature of my browser: the alt text is only displayed as hoverover / mouseover text in Safari after waiting a few seconds, even when images are not loaded. I should try Opera. --Jeisenbe (talk) 06:45, 10 August 2019 (UTC)

Resolved: Mateusz Konieczny (talk) 11:36, 25 January 2021 (UTC)

Wikidata

Wikidata-Links with a prefixed "P" e.g. P137 for operator=* do not lead to the desired page (P137).--geozeisig (talk) 10:48, 11 September 2017 (UTC)

@Geozeisig: It appears to work now Mateusz Konieczny (talk) 18:43, 21 May 2020 (UTC)

@Mateusz Konieczny: It does not work for property.

Example P1937 in ref:LOCODE=*. Link to https://www.wikidata.org/wiki/P1937 but must be https://www.wikidata.org/wiki/Property:P1937

--Pyrog (talk) 12:26, 4 August 2020 (UTC)

@Pyrog: - |wikidata=Property:P1937 works, is it sufficient? Mateusz Konieczny (talk) 16:18, 24 January 2021 (UTC)

Resolved: solving as solved by workaround Mateusz Konieczny (talk) 12:37, 26 March 2021 (UTC)

xmas:feature link to taginfo

The link by xmas:feature to taginfo is not correct at the moment. https://taginfo.openstreetmap.org/keys/xmas%253Afeature

https://taginfo.openstreetmap.org/keys/xmas:feature would be correct

--Rza31 (talk) 08:20, 2 December 2017 (UTC)

https://wiki.openstreetmap.org/wiki/Key:xmas:feature - taginfo link appears to work now Mateusz Konieczny (talk) 16:19, 24 January 2021 (UTC)

Resolved: seems solved Mateusz Konieczny (talk) 12:37, 26 March 2021 (UTC)

Remove IE link?

Since the IE taginfo site is currently not working (not been updated since October 2019 according to Taginfo/sites), should it be removed from the "Tools for this tag" section of this template? Seems odd to be linking to badly out-of-date information. Casey boy (talk) 09:33, 20 April 2021 (UTC)

+1 to removal if not updated since 2019 Mateusz Konieczny (talk) 10:08, 20 April 2021 (UTC)

For Ireland there are other Taginfo websites available: Britain and Ireland and Ireland and Northern Ireland. They're not the same but updated daily. maro21 20:13, 20 April 2021 (UTC)

Thanks, that's useful to know. We could change the link to the Ireland and Northern Ireland Taginfo site (I'd recommend against "Britain and Ireland" as there is already a GB link). To be honest, I don't really know what qualifies having a link on there at all really... Casey boy (talk) 17:38, 21 April 2021 (UTC)

Tag pages in English have links to Taginfo in English speaking countries, German version has links to German speaking countries and so on... It's not complete, there is no US for example, but anyone can edit and change it. maro21 18:49, 21 April 2021 (UTC)

Ah that makes sense. I see someone has actually added a US link to the English version recently but the IE link is still to the out-of-date page. Could I ask how I might change it? It's not apparent to me - sorry! Casey boy (talk) 09:36, 1 May 2021 (UTC)

You asked us here in the first message if the link should be removed. Me - I don't know. If you want, I can remove it, let me know. maro21 14:13, 1 May 2021 (UTC)

Sure, I realise that. I was following up. I think editing the link to the Ireland and Northern Ireland site makes the most sense since it's more regularly updated. Casey boy (talk) 19:04, 1 May 2021 (UTC)

I unlinked Ireland. But I don't know what to do with the island of Ireland becuase it's not a country and doesn't have its ISO 3166 code. maro21 19:42, 1 May 2021 (UTC)

Resolved: Mateusz Konieczny (talk) 22:11, 23 February 2022 (UTC)

How about 'pattern' or 'regex_pattern' ?

We could add a generic pattern key, which would not be shown to normal users (because it's only useful to programs or advanced users) and would contain a regular expression to find typos and/or errors (the regular expression would be able to validate every possible good value this key could have, and trying to avoid false negatives).

For example:

the key layer=* would have as pattern the regular expression ^(0|-?[1-5])$ (number from -5 to 5).
The key contact:website=* would have ^(https?://)?([a-z0-9-]+\.)+[a-z]{2,4}(/.*)?$ (a valid URL) (note: this regular expression doesn't support IP numbers).
The key population=* would have ^[0-9]{,10}$ (integer number from zero to 9 billion).
The key width=* would have ^([0-9]*(.[0-9]+)?( ?([ck]?m|mi|ft))?|[0-9]+'([0-9]+\")?)$ (quite permissive regular expression, you can test it here).
The key name=* would have [^\s]+ (has a sequence of one or more non-whitespace characters).
Etc.

The flavor of regular expression would be POSIX extended, which is the one used by the Overpass API (I should note that there are some small differences between in regular expressions between the Overpass XML Flavor and OverpassQL Flavor, and the one used should be the Overpass XML Flavor because it reduces some unnecessary character escaping)--Jgpacker (talk) 14:52, 3 May 2014 (UTC)

Good idea! It is right place to put in documentation (i.e. this wiki) instead of some program code. OSM data used by many users, sometimes not really involved in full stack of OSM technologies. Xxzme (talk) 03:23, 22 July 2014 (UTC)

I think we have discussed this idea previously. As long as it isn't visible in the infobox by default for normal users, I'm fine with it. I have some questions and ideas, though:

Which mechanism you would use for hiding this from normal users? Not show it at all and only have it visible in the source, or would there be some option to make it visible?
There are some value types which are used with multiple keys, e.g. length, width, and height (which are documented here. Would it be possible to prevent duplicating the regular expressions for these?

--Tordanik 16:33, 22 July 2014 (UTC)

Hi Tordanik,

I think either it wouldn't be displayed (only documented and visible in code), or a link would be added besides the overpass turbo link, adding something like <a href="overpass turbo with regexp">(with regexp)</a>.
I'm afraid it wouldn't be possible to avoid duplicating the regular expression for these keys.

--Jgpacker (talk) 14:17, 23 July 2014 (UTC)

It seems that (if done) then it would fit better data items, right? Where it could be displayed Mateusz Konieczny (talk) 16:24, 24 January 2021 (UTC)

Resolved: should be added to data items (adding to infoboxes parameters and not displaying it makes no sense - and there is no objection to this claim Mateusz Konieczny (talk) 22:13, 23 February 2022 (UTC)

move statuslink after all status values

currently the order in the doc is :

status: the approval status of this feature; possible values include:

statuslink: name of the proposal page, for linking

status1

status2

it should be :

status: the approval status of this feature; possible values include:

status1

status2

statuslink: name of the proposal page, for linking

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

I think you are right. --Hufkratzer (talk) 11:14, 8 June 2019 (UTC)

Resolved: done Marc marc (talk) 14:38, 8 June 2019 (UTC)

I do not think you would have needed to ask for such a small change in the documentation. This box is put on the doc page along with the rest of the documentation, but it is actually about the documented template itself. --Tigerfell

(Let's talk) 15:02, 8 June 2019 (UTC)

so the warning should be removed on the doc page ? Marc marc (talk) 20:44, 13 June 2019 (UTC)

If you think that warning is confusing you may improve/propose to improve wording of Template:Heavily used template Mateusz Konieczny (talk) 10:08, 14 June 2019 (UTC)

I think {{Heavily used template}} could be moved from {{ValueDescription/doc}} to {{ValueDescription}} ("...<noinclude>{{Heavily used template}}{{documentation}}</noinclude>" ). Then it would be more clear that the warning belongs only to the template itself. --Hufkratzer (talk) 10:25, 14 June 2019 (UTC)

I do not see a benefit in changing this. It even says "This template is used on a lot of pages!". --Tigerfell

(Let's talk) 14:37, 14 June 2019 (UTC)

Resolved: it seems that no further action needs to be taken and discussion is stale Mateusz Konieczny (talk) 10:10, 27 February 2022 (UTC)

Rendering of areas

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

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

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

I agree that they take too much space, but then I feel they should not be in the infobox to begin with. To me, that's mostly a concession towards Taginfo's limitations, not the best possible presentation on a wiki page. --Tordanik 10:31, 4 June 2017 (UTC)

For reference, affected revision looked like that: https://wiki.openstreetmap.org/w/index.php?title=Tag:leisure%3Dgarden&oldid=1467936 I suspect that something with reduced vertical size would work well Mateusz Konieczny (talk) 10:26, 16 April 2019 (UTC)

Resolved: Nowadays seems solved - if not, please link problematic pages Mateusz Konieczny (talk) 22:14, 23 February 2022 (UTC)

Remove wikidata from this template

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

This has been done now, seeing there were no objections. --Jeisenbe (talk) 21:34, 8 May 2020 (UTC)

If you really think there were no objections in the linked discussions you need to re-read them. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:14, 9 May 2020 (UTC)

Are you sure that you posted what you wanted to post? "seeing there were no objections." is clearly untrue. See linked https://wiki.openstreetmap.org/wiki/Template_talk:Description#Wikidata_link with "Hiding values is harmful; it leads to people not spotting errors." Mateusz Konieczny (talk) 18:59, 9 May 2020 (UTC)

To be clear, I fully support removal of this parameter. It still remains unclear why we would want such prominent links to Wikidata on OSM Wiki. Comment of edit was OK and without mistake like here in the discussion. Mateusz Konieczny (talk) 19:07, 9 May 2020 (UTC)

The reasons why have been explained to you previously. Whether you don't understand them or don't like them does not make them less real. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:15, 9 May 2020 (UTC)

"explained to you" - this is untrue. Given claims appeared to me extremely weak, I asked for clarification/conformation that was never made. Primary claimed use is bizarre case of someone frequently using Wikidata to query data about matching object, but not using data items and doing it manually based on infobox links. Maybe it is something rarely done by people, but it is not something that is highly important to describe OSM tags. Given extremely low data quality of links it appears that this is not used for anything. And putting this useless link above taginfo statistics is ridiculous. Mateusz Konieczny (talk) 23:59, 9 May 2020 (UTC)

Your claim that explanations have not been given is undermined by the fact that you have replied to those explanations Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:03, 10 May 2020 (UTC)

Explanations were weak, incomplete and unclear. To repeat myself "I asked for clarification/conformation that was never made". Some comments were made, but were insufficient to explain anything. Mateusz Konieczny (talk) 15:11, 10 May 2020 (UTC)

Those would be the explanations that you just denied were given? As I said, you not understanding them or not liking them does not make them less real. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:52, 10 May 2020 (UTC)

I meant that no one had objected during the current discussion period in 2020. The only objections were from Andy Mabbett in 2014 and 2018. --Jeisenbe (talk) 23:26, 9 May 2020 (UTC)

Well, technically Verdy_p also defended this link at https://wiki.openstreetmap.org/wiki/Template_talk:Description#Wikidata_link with justification that it should be kept because it makes "Wikidata finally useful", without explaining whatever and how it improves OSM Wiki. Mateusz Konieczny (talk) 00:17, 10 May 2020 (UTC)

Re: "Hiding values is harmful; it leads to people not spotting errors" - this appears to be the main objection? The problem is that I consider almost all of the current wikidata values on Tag and Key pages to be errors, since they usually link to the general wikidata concept which is similar to the key or value, rather than linking to a wikidata item specifically about the OpenStreetMap tag. --Jeisenbe (talk) 23:26, 9 May 2020 (UTC)

Re: "machine-readable metadata"... is available from the link at wikidata: this is usually incorrect, since most of the wikidata links are to a related, general concept like e.g. "cemeteries", rather than what landuse=cemetery means in OpenStreetMap and how it is different from an amenity=grave_yard. Occasonally the wikidata item is one that was made up specifically to link to the OpenStreetMap tag, but in that case there is no additional data available at wikidata which you can't find here or in the Data Items (wikibase). --Jeisenbe (talk) 23:26, 9 May 2020 (UTC)

You don't get to arbitrarily reset the clock. That the discussion has been open for some time does not invalidate comments made in it. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:03, 10 May 2020 (UTC)

I attempted to review discussion and my summary is as follows: there is a consensus for removal of Wikidata link from the infobox template, there is no unanimous support for that as for example Pigsonthewing and Verdy_p opposed. There is no clear use case for such link in the context of editing OSM. Such Wikidata links are confusing (identifiers are not human friendly, collision with Data item identifiers), are not important enough to be linked in infobox. Also, such links may confuse people about copyright status of Wikidata database. Wikidata database due to copyright differences us uneligible for import into OSM. It contains content systematically copied from copyrighted databases, for example English Wikipedia encourages copying location info from Goggle Maps what was (is?) then automatically copied into Wikidata (note: this may not be copyright/copyright-like violation under US law, but it is problem under UE rules). In general this wikidata link is not adding any additional information about OSM tags and is not a significant help in any OSM task. Also, presence of this link in infobox misleads people into wasting time on adding them. I plan to remove this parameter and ask Pigsonthewing to not reintroduce it. Maybe we are mistaken, but this Wikidata link is clearly unwanted, unsupported, undesirable and considered as nearly/completely useless for OSM mappers. Note that this links (with their highly dubious quality and usefulness) will remain in data items. If someone wants to do something rare, unusual, and in general not useful for OSM mapping like using Wikidata or its query service, and link between OSM tag and Wikidata item will be assumed to be true, then use https://wiki.openstreetmap.org/wiki/Property:P12 on data items. And if Pigsonthewing or someone else is convinced that discussion was mishandled, not presenting full facts or in some other way faulty - feel free to start discussion about reintroducing this parameter, and in case of support similar to one expressed its removal will be voiced then it can be added back (note that discussion should take place in standard appropriate discussion location like OSM Wiki talk pages or talk mailing list). Mateusz Konieczny (talk) 07:06, 10 May 2020 (UTC)

Your partisan reading of the discussion does not accord with reality; it is not for you to act as judge, jury and executioner. I have restored the status quo ante. You need to cease your edit warring and wait for a natural and recognisable consensus to emerge. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:59, 10 May 2020 (UTC)

You seem to confuse consensus and unanimous support. In this case we have a widespread agreement and extreme minority opposing it. It means that there is no unanimous support but we have a consensus to make this action. "it is not for you to act as judge, jury and executioner" - good idea. I will try to @Tigerfell:, maybe he will be interested in reviewing this situation. "wait for a natural and recognisable consensus to emerge". I am pretty sure that it already emerged in discussions. Mateusz Konieczny (talk) 15:16, 10 May 2020 (UTC)

"You need to cease your edit warring". We have no strictly defined limit of what becomes an edit war, but Pigsonthewing is sole recent editor on this page who crossed 3 revert rule used on English Wikipedia - "there is a bright-line rule called the three-revert rule (3RR), the violation of which often leads to a block." and on enwiki you would almost certainly receive short term block. Please avoid doing something and immediately accusing others of doing that Mateusz Konieczny (talk) 15:22, 10 May 2020 (UTC)

I am not confusing anything. HTH. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:52, 10 May 2020 (UTC)

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

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

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

proposal voting to remove seems unusually high barrier given that it was added without any real discussion (adding it was OK, I assume that whoever added it wanted to improve OSM Wiki) Mateusz Konieczny (talk) 11:36, 11 May 2020 (UTC)

Still, sooner or later I will make such proposal. Pigsonthewing, if you think that there is better defense of Wikidata linking than summary by Tigerfell feel free to state it and I will include it in this proposal. Mateusz Konieczny (talk) 11:39, 11 May 2020 (UTC)

I believe the proposal should ask the question "Should the Wikidata link be added to the Infobox?" - because the original addition of this feature was not approved by the community in this way. --Jeisenbe (talk) 00:47, 12 May 2020 (UTC)

Still, support for this link is so low that I expect that any kind of voting will result in its removal (making it quite redundant, but it may be easier than this ongoing discussion) Mateusz Konieczny (talk) 20:00, 12 May 2020 (UTC)

Proposed features/remove link to Wikidata from infoboxes is now getting created Mateusz Konieczny (talk) 18:55, 7 January 2021 (UTC)

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

I

Support removing Wikidata from this template, in particular when no parameter is given. "Search Wikidata" doesn't work anyway. maro21 15:36, 3 May 2021 (UTC)

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

Wikidata

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

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

Wikidata link

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

Please do not remove the Wikidata link. The hookum that this "can frighten new users" is without foundation, and we are not going to run out of space on our wiki pages. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:44, 30 December 2014 (UTC)

I agree that it can be slightly problematic. Most users probably don't know what Wikidata is. Wikipedia links are more usable/friendly and often available in the wiki page. As Wynndale pointed out, we can leave the parameter without making it visible. --Jgpacker (talk) 14:27, 30 December 2014 (UTC)

You may agree, but where is the evidence? Hiding values is harmful; it leads to people not spotting errors. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:05, 30 December 2014 (UTC)

"Hiding values is harmful; it leads to people not spotting errors." - (a) I support removal also of such unused parameter from article text. (b) infobox is not a place to put anything at least a bit related and every single possible link, as Wikidata link has nearly no use I support its elimination Mateusz Konieczny (talk) 18:58, 9 May 2020 (UTC)

"Wikidata link has nearly no use" is false. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:10, 9 May 2020 (UTC)

How it is supposed to be used? Primary claimed use is bizarre case of someone frequently using Wikidata to query data about matching object, but not using data items and doing it manually based on infobox links. Maybe it is something rarely done by people, but it is not something that is highly important to describe OSM tags. In addition links are very often misleading because Wikidata items and OSM tags very rarely match 1:1 Mateusz Konieczny (talk) 00:05, 10 May 2020 (UTC)

Wynndale, so what is your proposed action? What does Wikipedia use to link to Wikidata?--Jojo4u (talk) 13:08, 7 February 2015 (UTC)

Wikipedia uses Wikidata by searching in it an item that matches the current page name (in the "wikipedia" properties). When an entry is found, it will list the other "wikipedia" links found in the matching Wikidata entry (those entries will be added to those for which there are explicit interwikis to specific wikipedias (but those are now deprecated and no longer necessary: if they are present, they override the interwikis found in Wikidata for the same language, and the link found in Wikidata will not be displayed; but Wikipedia will still incldue a link at the bottom of the list to show the existing Wikidata page that has been found).

However this OSM wiki still does not know how to query Wikidata to retrieve a list of Wikipedias (in fact this wiki does not perform any query to Wikidata, it does not even have an interwiki for it, so we link Wikidata via wikipedia, or use absolute URLs). Effectively this wiki does not have the MediaWiki extension for the Wikidata client. — Verdy_p ^(talk) 17:11, 26 May 2015 (UTC)

"Wikipedia uses Wikidata" this is not relevant at all. How adding wikidata parameter to Description template helps anything in OSM wiki? Mateusz Konieczny (talk) 12:34, 4 November 2017 (UTC)

You truncate a sentence that explains what Wikipedia does to retrieve the list of other wikipedias on the same topic: yes it uses Wikidata.

So the question is: do we need Wikidata or Wikipedia links? If we need Wikipedia, it is do avoid having to document many things, but a single Wikipedia is not relevant for all, and other languistic editions are relevant as well, but we cvannot link hundreds of Wikipedias! So we can link to Wikidata and this gives the full list of Wikipedia, plus many other classifation data and useful data from Wikidata only without having to read the full rendered Wikipedia articles. With Wikidata we also get links to Commons (for galeries, categories, or documents such as book scans, or Wikisource, or definitions in Wiktionary, and really many sources). Wikidata has a solid categorization system which includes many qualifiers, it gets always better, and often will be a better reference now than a single Wikipedia article (where multiple topics will be frequently merged even iof they are clearly distinguished in Wikidata).

Not all cities in the world have a Wikipedia article in any language (or sometimes only in an unrelated language), but all those that have a pedia article will also have an entry in Wikidata (if not, it is instantly created). Wikidata is more inclusive (against forgotten missing items) and more precise in all cases (ans also more accessible).

But we don't have Key or Tag wiki pages for individual cities, we have a page place=city which is used in a way that is much different than the definition of "city" in US English or British English. Even more different are the place=suburb vs https://www.wikidata.org/wiki/Q188509. --Jeisenbe (talk) 23:55, 9 May 2020 (UTC)

Wikidata is finally useful beause its classification of concepts is more precise, and more checked (before that, it was partilly checked on Commons, but never really checked on English Wikippedia, and this caused problems when articles in Wikipedia were renamed, merged, and split in separate articles (the main topic was actually changed, this should never happen in Wikidata that will preserve the explicit distinctions). — Verdy_p ^(talk) 15:54, 4 November 2017 (UTC)

"Not all cities in the world have a Wikipedia article in any language" how it is relevant to linking to wikidata from description of tags? Mateusz Konieczny (talk) 16:15, 4 November 2017 (UTC)

"Wikidata is finally useful beause its classification of concepts is more precise, and more checked" - can you give any example of using this classification in context of OSM tags? Mateusz Konieczny (talk) 16:15, 4 November 2017 (UTC)

"With Wikidata we also get links to Commons" - images, if useful, may be already directly placed or linked from articles Mateusz Konieczny (talk) 16:15, 4 November 2017 (UTC)

"Wikidata is finally useful" - putting useless links to inflate supposed Wikidata use is not a good idea. It is an OSM Wiki, not promote Wikidata WIki Mateusz Konieczny (talk) 00:12, 10 May 2020 (UTC)

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

One discussion place

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

Good idea. My plan is to mark old resolved discussion as resolved, archive them, move still active discussions here, merge archives, redirect archived, redirect talk pages Mateusz Konieczny (talk) 22:26, 9 January 2021 (UTC)

I would also include sharing talk pages of /doc subpages Mateusz Konieczny (talk) 08:04, 22 January 2021 (UTC)

I agree, let's do it. --Jeisenbe (talk) 17:46, 24 January 2021 (UTC)

Resolved: done Mateusz Konieczny (talk) 22:45, 1 May 2022 (UTC)

Category:Feature pages with missing images

Resolved

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

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

Maybe "Tagging pages with missing images"? Mateusz Konieczny (talk) 03:08, 23 July 2021 (UTC)

@Maro21: are you planning to do this? Mateusz Konieczny (talk) 07:28, 9 March 2022 (UTC)

I was planning to do this, but something stopped me. I don't remember now what was it, I need to check it again. maro21 22:12, 9 March 2022 (UTC)

So I created Category:Tag and key pages with missing images. I left Category:Feature pages with missing images which contains non-tag and non-key pages. maro21 14:02, 20 March 2022 (UTC)

Documented values

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

I also noticed this problem. I agree it can be a little confusing. --Jgpacker (talk) 20:34, 11 July 2014 (UTC)

Seems to work now after someone split categories into separate languages @Chrabros:, @Jgpacker: - is it still a problem? Mateusz Konieczny (talk) 11:30, 25 January 2021 (UTC)

Resolved: no known examples of breakage Mateusz Konieczny (talk) 22:57, 1 May 2022 (UTC)

Wikidata

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

If we support the parameter there, it should be supported here, too. But first it would be advisable to actually document the new wikidata parameter properly. Currently an explanation is missing from the template description, only its existence is noted. And while I find the idea interesting in general, I would also like to see some examples on how to use it (and how not to use it). I don't think this is self-evident. (I also dislike the complete lack of discussion preceding its introduction, by the way.) --Tordanik 01:49, 30 August 2014 (UTC)

It’s been added to Key:bridge. The icon for missing translations can be fixed if it’s worth keeping. I can’t say I’m convinced yet.--Andrew (talk) 08:04, 30 August 2014 (UTC)

Indeed. That example already points to a problem: While it is sometimes possible to state that all OSM elements with that tag are an instance of some Wikidata item, it is not possible in other situations. For example, roads with bridge=yes crossing a man_made=bridge are not instances of "bridge". Furthermore, a lot of OSM tags don't represent an instance relationship with some class of objects at all, but are properties instead. So I doubt that mapping Wikidata onto OSM tags in that manner is feasible. --Tordanik 21:47, 1 September 2014 (UTC)

So far I do not see any new value of this new wikidata feature. Maybe someone could try to explain its purpose in better example than is Key:bridge. Chrabros (talk) 07:39, 3 September 2014 (UTC)

What is purpose of this parameter? I see plenty of edits adding it and I missing any use for it. At this point I recommend removing it. Mateusz Konieczny (talk) 12:28, 4 November 2017 (UTC)

I plan on removing this parameter. Is anybody opposed and able to explain purpose of this parameter? What is purpose of linking Wikidata entries from tag pages? How it can be used to improve OSM? Mateusz Konieczny (talk) 08:35, 3 January 2018 (UTC)

I am opposed to removing the wikidata parameter. Its purpose is that by clicking on the link one can quickly find more information that explains what the tag is about, at least it should be used in way that this is the case.

Wiki_Translation#Community_cohesion: "Unlike Wikipedia, we are not aiming to capture vast amounts of knowledge in the wiki." So what else than links do you want to use? I assume that most people who have added wikidata IDs here thought that this would be helpful for other users, so that not everyone has to search by himself.

There is not always a corresponding wikidata item available or there may be other problems in some or perhaps in many cases, then the parameter can be omitted (and I think the "Search Wikidata" link is dispensable in this case), but that's no reason to remove the parameter in general (like it would also not be great to remove the "Available languages" bar everywhere just because there are sometimes contradictory statements in different languages).

Please make more clear what exactly you are planning to remove: The link if "wikidata = Q..." is set, or the link to the wikidata query window if it is not set ("Search Wikidata"), or both? --Hufkratzer (talk) 17:52, 4 January 2018 (UTC)

"Its purpose is that by clicking on the link one can quickly find more information that explains what the tag is about" - note that wikidata entries and OSM tags rarely match perfectly. I would not rely on this kind of links to explain how tags should be used Mateusz Konieczny (talk) 20:55, 10 November 2018 (UTC)

"Please make more clear what exactly you are planning to remove" - link, "search wikidata" link and all "wikidata" parametres added on Wiki pages Mateusz Konieczny (talk) 20:56, 10 November 2018 (UTC)

I asked Geozeisig who is often adding this parameter for help as I am still unaware how and why this parameter is added and used Mateusz Konieczny (talk) 15:56, 2 January 2018 (UTC)

Geozeisig replied in https://wiki.openstreetmap.org/w/index.php?title=User_talk:Geozeisig&diff=1542792&oldid=1542485&rcid=&curid=50235 "Sorry, I do not know the purpose of this parameter". Mateusz Konieczny (talk) 08:35, 3 January 2018 (UTC)

I asked Pigsonthewing who added this parameter Mateusz Konieczny (talk) 09:58, 3 January 2018 (UTC)

Thank you, Mateusz. I would, of course, be opposed to removing this very useful feature. I'm not clear what the objection to it, other than "I don't understand it", is. Perhaps the lack of understanding is caused by the poorly-chosen examples ("cheescake"?!?). The example for "power = generator" is slightly better, because the Wikidata search returns a real item, Q131502. But even that seems to be conflated with Tag:power=plant. A far better example (one of many correct uses) is Tag:landuse=cemetery; where there is an explicit link to Wikidata's Q39614 item. There, once can see machine-readable metadata about cemeteries, and query Wikidata for items about cemeteries (or of sub-classes or super-classes thereof), which can be cross-referenced with those in OSM to check for matches and discrepancies. The use of links (URIs) to such data ("linked data") both on thsi direction and the reverse (from Wikidata to OSM pages) is exactly what Sir Tim Berners Lee, the inventor of the World Wide Web, calls for (video, with text transcript). It is vital that OSM is part of the web of linked data, if its full potential is to be realised. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:24, 3 January 2018 (UTC)

Could we please leave politics (and religion so to speak) out of this? Mateusz asked for the specific purpose of the parameter. 'Linking' in itself is not a purpose. The question is what kind of relationship this reference indicates. How is this reference used/supposed to be used? As the meaning and use of tags change how do you determine if a certain value of this parameter is correct of not? landuse=cemetery and amenity=grave_yard have the same wikidata value. Is this correct? waterway=river references Q4022 but waterway=stream does not. Is this correct? How does the mapper editing the wiki determine if it is or not? What would be the wikidata value for something like access=* or opening_hours=*? See also Tordanik's remarks above. --Imagico (talk) 15:17, 3 January 2018 (UTC)

I don't know about "politics and religion", because I used neither. I did though explain the purpose of including the links to Wikidata. What about you leaving out the snark and the assumption of bad faith? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:38, 3 January 2018 (UTC)

I referred to "is exactly what Sir Tim Berners Lee, the inventor of the World Wide Web" - claiming that some authority supports it, without decent confirmation is a poor argument. I am pretty sure that he would not support useless linking not giving any clear benefits Mateusz Konieczny (talk) 20:54, 10 November 2018 (UTC)

"what the objection to it" - iff it is not clearly useful then there is no reason to keep it in infobox Mateusz Konieczny (talk) 15:29, 3 January 2018 (UTC)

Fortunately, it is clearly useful, as I explained. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:38, 3 January 2018 (UTC)

Are you claiming that "machine-readable metadata about cemeteries, and query Wikidata for items about cemeteries" is needed so often by users of OSM Wiki that it deserves to prominently displayed in the infobox? Because it seems to me that such things will be done rarely, and it is as relevant as linking relevant Wikimedia Commons category, Wiktionary item, Flickr category etc. I see no reason to elevate Wikidata so high, it is not like OSM Wiki is about promoting this project Mateusz Konieczny (talk) 19:05, 9 May 2020 (UTC)

"machine-readable metadata about cemeteries" - how it helps doing anything in OSM? Mateusz Konieczny (talk) 15:29, 3 January 2018 (UTC)

Not everything in OSM, or the OSM wiki, has to "help doing anything in OSM". The purpose is to "help OSM's users". Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:38, 3 January 2018 (UTC)

"help OSM's users" for me is included in "help doing anything in OSM". So how this kind of "machine-readable metadata about cemeteries" (only sort-of related to OSM tagging scheme) helps doing this? Mateusz Konieczny (talk) 20:50, 10 November 2018 (UTC)

"query Wikidata for items about cemeteries" - how this link from infobox is helpful in making queries? In my experience main obstacle in making queries is figuring out syntax of SPARQL and searching for identifiers is easy. Also, https://www.wikidata.org/wiki/Q39614 anyway has nothing that would allow making Wikidata query that is not already present on https://www.wikidata.org/wiki/Wikidata:Main_Page. In addition, is it really common for users of OSM wiki to make Wikidata queries? Mateusz Konieczny (talk) 15:29, 3 January 2018 (UTC)

[Outdent]

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

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

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

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

"query Wikidata for an up-to-date list of items about cemeteries" - so only usage is to make searching Wikidata easier? Why we would need it? What makes Wikidata so special that infobox needs a special link to search in this particular database? Mateusz Konieczny (talk) 21:00, 10 November 2018 (UTC)

The OSM linkages on Wikidata can already be quite useful to create automatic translations of most tags. Its probably a better idea to store the links on Wikidata which is a proper database rather than the OSM Wiki though. If there was some way this wiki could query Wikidata and automatically add links to Wikipedia, and images from Commons, it would be super helpful in the lesser represented languages --Planemad/Talk 08:06, 10 January 2018 (UTC)

As discussed in comments in this diary entry - "The problem with using wikipedia / wikidata for this is that the words that OSM uses to describe things often don't match the dictionary definition (in any language, even British English) of those things, even for basic things like "city"." Mateusz Konieczny (talk) 21:02, 10 November 2018 (UTC)

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

This is what Mateusz already suggested above. The only purpose of the wikidata parameter mentioned so far except the self fulfilling linking of data are to find more information that explains what the tag is about and automatic translation - which as it has been explained do not work since there is no semantic identity between the tag and the linked to wikidata entry and the illusion of such identity is misleading for the mapper. Because of this an automatic translation based on the assumption this identity exists is bound to be faulty which rules out this application as well. Plenty of examples given above that illustrate this. So i also see no good reason to keep this. It does more damage by misleading mappers than it provides actually useful information (which essentially amounts to someone thought this wikidata entry is somehow related to this OSM tag). --Imagico (talk) 16:27, 8 November 2018 (UTC)

Now we have our own Wikibase there’s another problem. The Wikidata link has a database link (Q number) that is different from the Q number in our own Wikibase instance. The WMF developers were very un-keen on Yuri’s suggestion of us using a different prefix letter to distinguish the two. Getting rid of the Wikidata parameter would solve this.--Andrew (talk) 06:26, 9 November 2018 (UTC)

Another user asked on the craft page:

"What to do if there is more than one Wikidata counterpart implied with craft=*? There is "craft" - Wikidata:Q2207288 - but usage in OpenStreetMap also implies "skilled trade" - Wikidata:Q64506407.

; Options

Note down all Wikidatas (with semicolon) even if that's not currently supported? (e.g. wikidata=Q2207288;Q64506407)
Link to the literal expression?
Put in the best match? (Here you could prefer "skilled trade", covering a wider range of usage than "craft".)
Leave it empty? (How many percent of matching is needed? Better a link with 75% matching or no link?)

I'm undecided myself and tend to 1 or 2 for now. (Perhaps "skill" would have been a more universal key than "craft".) --Chris2map (talk) 07:41, 3 May 2020 (UTC)

This is another reason that "wikidata=" should not be used in the Description templates (which create the Infobox), because it usually does not work. --Jeisenbe (talk) 16:04, 3 May 2020 (UTC)

Bald statements that something "usually does not work" do not inform the debate: you need to say what you mean by "usually does not work", you need to give examples, and you need to say what you have tried to remedy the examples you give and how that failed. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:59, 3 May 2020 (UTC)

The sensible solution, missing from your list, is to either use a parent item on Wikidata, that encompasses both of the child items which cause you an issue; or to start a discussion on Wikidata, to ask the community there to resolve the issue. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:59, 3 May 2020 (UTC)

Though in this case, "craft" is the parent of "skilled trade" (and not vice versa as you have it) and is the correct item to use here. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:08, 3 May 2020 (UTC)

Because items on wikidata relate to real-world concepts, while tags in OpenStreetMap are used in particular ways which have developed over time, attempts to link to a wikidata page will not find a good match. An example is how landuse=cemetery and amenity=grave_yard were both linked to https://www.wikidata.org/wiki/Q39614 - "place of burial", however the wiki pages for those tags note that they are not identically: amenity=grave_yard is used for churchyards and other grave sites located next to a place of worship, while landuse=cemetery is generally used for burial sites that are not associated with a place of worship. Similarly, the key craft=* does not match the definition on wikidata: https://www.wikidata.org/wiki/Q2207288 "pastime or profession that requires particular skills and knowledge of skilled work" vs our definition https://wiki.openstreetmap.org/wiki/Key:craft "A place producing or processing customized goods". Notice that the wikidata definition is of a hobby or job and focuses on skills + knowledge, while the OpenStreetMap tag is a location and focuses on making or processing goods. But also "places that are widely accepted as shops should not be tagged as crafts". Comparing the German and English wikipedia definitions might explain why wikidata and OpenStreetMap don't match: https://als.wikipedia.org/wiki/Handwerk vs https://en.wikipedia.org/wiki/Craft - but it's also due to the fact that craft=* was accepted long after many things were tagged as amenity=* or shop=* or man_made=*. Reading the linked wikipedia articles on the wikidata page will not help mappers or database users to understand what the key is used for in OpenStreetMap. --Jeisenbe (talk) 23:43, 9 May 2020 (UTC)

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

Merge discussions

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

Resolved: this happened now Mateusz Konieczny (talk) 20:46, 4 August 2022 (UTC)

Examples in documentation

Resolved: now changed --Chris2map (talk) 12:11, 25 March 2023 (UTC)

The documentation of this template mentions many examples, like:

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

or

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

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

@Maro21: I would be fine with this Mateusz Konieczny (talk) 20:45, 4 August 2022 (UTC)

I removed the examples on Description/doc and added links to the specific template docs (key, value, prefix, suffix) and moved missing examples there. --Chris2map (talk) 12:11, 25 March 2023 (UTC)

display title

Resolved: now fixed Mateusz Konieczny (talk) 08:42, 3 August 2022 (UTC)

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

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

Deprecation of parameter "seeAlso"

Resolved: substantial change, no clear support for it -marking as resolved and will archive unless someone protestsMateusz Konieczny (talk) 08:29, 3 August 2022 (UTC)

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

I quite like seeAlso section. It seems to me very easy to read and sometimes useful. I wouldn't deprecate it. Chrabros (talk) 06:58, 14 July 2014 (UTC)

I prefer the traditional "See also" section. As an infobox parameter, this can get quite large and inflates the size of the box, pushing images and similar content too far towards the bottom of the page. The "See also" section also allows adding a description to the link, which is not possible in the infobox. It's ok if people want to keep it around, but I'm not a fan. --Tordanik 19:49, 15 July 2014 (UTC)

Small section in infobox is good place to link page with other tags. Use bigger section if you need to post external links. Don't move tags is infobox. Xxzme (talk) 19:58, 15 July 2014 (UTC)

So what do we do now? Users are starting to simply copy all tags from the "See also" section on the bottom of the page into the infobox, without any explanatory text. I still believe that the seeAlso parameter shouldn't have been added. The infobox needs to be used sparingly, only showing the most important information. --Tordanik 20:21, 26 March 2015 (UTC)

I agree that it is pointless and should not be present but I am not bothered enough to deal with removing it Mateusz Konieczny (talk) 22:29, 23 February 2022 (UTC)

Script errors based on input

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

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

@Yurik: - any idea what is happening in Pt:Tag:place=square? Mateusz Konieczny (talk) 18:12, 24 January 2021 (UTC)

Resolved: Seems to be solved. No more key or tag pages in Category:Pages with script errors. --Chris2map (talk) 18:26, 14 March 2023 (UTC)

Stop Feature pages with missing images for deprecated tags

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

+1 --Tigerfell

(Let's talk) 13:11, 8 June 2020 (UTC)

Resolved: https://wiki.openstreetmap.org/w/index.php?title=Template:Description&diff=2391875&oldid=2389546 Mateusz Konieczny (talk) 08:44, 13 September 2022 (UTC)

How to remove the "red pencil" in deprecated features

Resolved: at least here, this bugginess remains unsolved Mateusz Konieczny (talk) 08:31, 3 August 2022 (UTC)

I am following the guidelines to have the same description in the Data Item as well as in the description. However, I have found some deprecated features that use another tag, and it still appears the red pencil on the label. How can I correct that? I have tried different ways, and I haven't found the solution. The issue is that the deprecated tag adds some text in the description "El uso de esta etiqueta está desestimado, usa" in Spanish.

This is an example of deprecated value, and the red pencil still appears: ES:Tag:healthcare=community health worker --Angoca 15:37, 15 June 2022 (UTC)

The solution is not to use the buggy {Deprecated} template, use {Description}. I fixed this page. maro21 23:03, 25 June 2022 (UTC)

Introducing `group=transport modes`

Resolved: proposal was withdrawn, see https://wiki.openstreetmap.org/wiki/Talk:Wiki/Archive_9#Introducing_Category:Transport_modes Mateusz Konieczny (talk)

Please discuss in Talk:Wiki#Introducing_Category:Transport_modes.

--Push-f (talk) 06:47, 28 June 2022 (UTC)

What should be done with pages describing prefixes?

Resolved: Proposed features/Documentation of key prefixes & suffixes Mateusz Konieczny (talk) 20:40, 4 August 2022 (UTC)

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

Taginfo should show 0 uses for such prefixes. And I think we should move Key:addr to Key:addr: or don't name such pages with "Key". I think addr is not a key, but for example addr:city. maro21 00:20, 30 October 2020 (UTC)

You are correct, addr: is not a complete key, in the database it is going to be something specific like addr:housenumber. Usually we link to the page Address instead. A key is simply a string of any characters, and there is nothing special about a colon (":") by nature. Although many application developers are familiar with this being used for "namespacing" in other contexts (including this wiki), all database users have to custom-design code to handle this, if desired. So it would be best to address actual, complete keys in the pages like Key:addr:city, or redirect those to a general article which is not prefixed with Key:. --Jeisenbe (talk) 03:55, 30 October 2020 (UTC)

My current idea is to have Prefix:addr:, Prefix:disused: with separate Template:PrefixDescription Mateusz Konieczny (talk) 11:07, 26 January 2021 (UTC)

I support it. But I think we should discuss it first on Talk:Wiki, not here. maro21 20:37, 26 January 2021 (UTC)

Let's continue the discussion >here<. --maro21 18:27, 26 June 2022 (UTC)