Template talk:Description: Difference between revisions
Jump to navigation
Jump to search
Resolved: it seems that example rendering is now in the template Mateusz Konieczny (talk) 18:15, 15 April 2019 (UTC)
(→Remove wikidata from this template: OK, there was also Verdy_p. I will not mention it by name because it would be "it is bad idea because Verdy_p agreed with it" what would be a quite low argument) |
(→Remove wikidata from this template: ::::"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 [https://en.wikipedia.org/wiki/Wikipedia:Edit_warring 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 avoi) |
||
| Line 1,348: | Line 1,348: | ||
:::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. <span class="vcard"><span class="fn">[[User:Pigsonthewing|Andy Mabbett]]</span> (User:<span class="nickname">Pigsonthewing</span>); [[User talk:Pigsonthewing|Andy's talk]]; [[Special:Contributions/Pigsonthewing|Andy's edits]]</span> 11:59, 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. <span class="vcard"><span class="fn">[[User:Pigsonthewing|Andy Mabbett]]</span> (User:<span class="nickname">Pigsonthewing</span>); [[User talk:Pigsonthewing|Andy's talk]]; [[Special:Contributions/Pigsonthewing|Andy's edits]]</span> 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 {{ping|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. [[User:Mateusz Konieczny|Mateusz Konieczny]] ([[User talk:Mateusz Konieczny|talk]]) 15:16, 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 {{ping|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. [[User:Mateusz Konieczny|Mateusz Konieczny]] ([[User talk: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 [https://en.wikipedia.org/wiki/Wikipedia:Edit_warring 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 [[User:Mateusz Konieczny|Mateusz Konieczny]] ([[User talk:Mateusz Konieczny|talk]]) 15:22, 10 May 2020 (UTC) |
|||
Revision as of 15:23, 10 May 2020
 | Please use the sandbox and the testcases for editors to experiment. |
Rationale for this new template
Back in October 2007 Etric Celine created the very first key description template as an attempt "to get a well designed structure into the available Keys that exist to describe a map feature." Over the more-than-six years since then, this approach has grown into nearly forty such templates in over twenty languages: Lazzko created the first non-English template in July 2008 in Finnish, and German, Italian, Hungarian and other languages followed later, with Catalan being the most recent addition.
Despite some fairly advanced template magic being present in the English-language template to provide language support, the templates for non-English languages were implemented separately, and their paths have diverged somewhat ever since. While this has allowed special customisation for the different requirements of each language community, this has also meant that changes and maintenance of such a wide number of templates has been difficult. We see that with the range of different levels of implementation of the various templates, some of which include some later features from the English templates, and many of which contain links to now-non-functioning external sites. It simply is a lot of work to understand, maintain and keep up-to-date this spread of templates.
And template designing and building isn't for everyone: the proportion of people with the knowledge, time and inclination to put effort into description templates is going to be a small one, meaning that in any given language community, that group is likely to be very small indeed. As OpenStreetMap builds and grows as a true multi-language project, there needs to be an emphasis on supporting non-English communities well, particularly the newer, smaller ones.
So this reimplementation of the {{KeyDescription}} and {{ValueDescription}} templates attempts to address some of these issues, and attempts to take a serious renovation of the current setups, without affecting the visible user experience in any significant way at all. Improvement for language support, increased consistency and ease of maintenance have been the key drivers here, as well as making a few small, cosmetic tweaks in an aim to improve the overall look.
Language support
This template has been designed from the outset to support full internationalization. By separating the formatting (title, headings, etc.) from the language content, the template can be used just as well on a Japanese-language page as an English-language one. As mentioned above, this approach for this template is not new — Miloscia pioneered this approach in August 2013 — but is taken further here.
By providing excellent language support, it will be possible to migrate non-English pages away from language-specific description templates to making use of this new template, allowing changes and fixes to take place in a single place, rather than in multiple locations.
The discussion here has been moved further down the page.
Maintainability
The existing {{KeyDescription}} and {{ValueDescription}} templates have developed over some time, and are now quite difficult to understand. The new templates are built from a series of smaller templates, each with its own documentation and test cases. The new template hierarchy is as shown:
{{Template:KeyDescription}}
{{Template:ValueDescription}}
|
+---- {{Template:Description}}
|
+---- {{Template:TagPagename}} <-- link to canonical pages for key, value
|
+---- {{Template:RelationPagename}} <-- link to canonical pages for relation
|
+---- {{Template:Languages}} <-- links to the same content in other languages
|
+---- {{Template:DescriptionCategories}} <-- categorises according to group, key, value, language
| |
| +---- {{Template:DescriptionCategory}}
|
+---- {{Template:DescriptionLang}} <-- provides translations for key content
| |
| +--- {{Template:TranslateThis}} <-- encourages reader to submit a new translation
|
+---- {{Template:GroupLink}} <-- hyperlinks group name
|
+---- {{Template:ElementUsage}} <-- shows which type of elements to use this on
| |
| +---- {{Template:ElementUsage2}}
| |
| +---- {{Template:ElementUsageLang}} <-- provides translations for element usage phrases
| |
| +--- {{Template:TranslateThis}} <-- encourages reader to submit a new translation
|
+---- {{Template:StatusLang}} <-- provides translations for statuses
| |
| +--- {{Template:TranslateThis}} <-- encourages reader to submit a new translation
|
+---- {{Template:DescriptionCategory}} <-- categorises according to status
|
+---- {{Template:DescriptionLinks}} <-- links to external web pages about this key, value
|
+---- {{Template:TaginfoLinks}} <-- generate links to taginfo instances
|
+---- {{Template:TaginfoLinksPerLanguage}} <-- which taginfo instances to link to for this language
The main template is also broken down into chunks, with some explanation in the comments of what each chunk contributes.
Personalisation
If you want to personalise the look of the description boxes, the new templates give you that option. The main box is a table with class description and either keydescription or valuedescription. You can add personal CSS rules on your personal wiki CSS page to change the CSS styles which are applied. For example, adding this code:
table.description { background-color: #ccf !important; border: 3px solid black !important; }
changes the colour of description boxes to blue, and adds a wider border. The following classes are also defined:
tr.d_image
|
the table row containing the feature image |
|---|---|
tr.header
|
the table rows containing the section headers |
tr.content
|
the table rows containing the section content |
tr.d_description
|
the table rows containing the feature description title and content |
tr.d_usage
|
the table rows containing the element usage title and content |
tr.d_combination
|
the table rows containing the "useful combination" title and content |
tr.d_implies
|
the table rows containing the "implies" title and content |
tr.d_seealso
|
the table rows containing the "see also" title and content |
tr.d_status
|
the table rows containing the feature status title and content |
tr.d_taginfo
|
the table rows containing the taginfo title and content |
tr.d_links
|
the table rows containing the external links title and content |
For example, if you do not want to see taginfo details at all, the following line on your CSS page will remove them completely:
table.description tr.d_taginfo { display: none; }
Cosmetic/minor tweaks
The following minor tweaks have been made in the new templates:
- top margin reduced from .2em to 0px
- image horizontally centred within box, not left-aligned
- thin space inserted either side of the '=' in the title of the value description box
- show/hide for tag tools removed, as very few tool lines needed
- default image changed from
to 
or 
as appropriate - values in box title hyperlinked to appropriate description page, allowing easy navigation where the description box is on a different page
- improved handling where important parameters are missing
- "group" and "status" information combined: header and value on same line to reduce vertical size of box
Side-by-side comparison
Each of the following is a real-life usage of one or other of the current description templates, taken from a page on this wiki. In the case of the current templates, the template has been subst:-ed and the language links removed, simply to make the table readable. The new template is called with exactly the same parameters, except for languagelinks = no to switch off the language links, and lang = ?? to indicate which language to use.
| Parameters | Current template | New template | |
|---|---|---|---|
{{ValueDescription
| key = highway
| value = trunk
| image = Image:Dscf0444 600.jpg
| description = Important roads that aren't motorways.
| onNode = no
| onWay = yes
| onArea = no
| lang = en
| combination =
* {{Tag|name}}
* {{Tag|ref}}
* {{tag|motorroad}}
* {{Tag|oneway|yes}}
* {{Tag|lanes}}
* {{Tag|destination}}
| implies =
* {{tag|surface|paved}}
}}
|
|
| |
{{Template:De:ValueDescription
| description=Ein Geschäft für Autoteile, Autozubehör, Motoröl usw.
}}
|
|
| |
{{KeyDescription
| image = File:Disused-pub.jpg
| key = disused
| value = *
| description = Namespace for features that have fallen into disuse, \
but which are still useful for navigation and visible in the landscape.
| group = Lifecycle
| onNode = yes
| onWay = yes
| onArea = yes
| status = In use
| seeAlso = {{tag|abandoned}}
| lang = en
}}
|
|
| |
{{Template:RU:KeyDescription
|key = cuisine
|image = Image:Burger 1 bg 080206.jpg
|description = Для описания типа еды предлагаемой в ресторане или кафе
|group = cuisine
|onNode = yes
|onWay = no
|onArea = yes
|onRelation = no
|lang = en
|combination=
* {{Template:RU:Tag|amenity|restaurant}}
* {{Template:Tag|takeaway||yes/no}}
* {{Template:Tag|diet}}
}}
|
|
|
.jpg)
Implementation plan
The following implementation seems sensible, with enough time for each stage/between stages to check that nothing is going too wrong.
- Stage 1: publish this outline here, encourage discussion, identify and address any bugs, problems, concerns or questions; use this template in a small number of real pages to check for compatibility across more real-world usages, languages, etc.
- The following pages are being used to test these templates:
- Stage 2: once reasonable consensus has been achieved, select a medium-sized language group and move usage of existing language-specific template to this one, checking for compatibility, readability, etc.
- Updated seven pages which included {{Fi:ValueDescription}} but did not have
lang =parameter specified: setlang = fi - Replaced Template:Fi:ValueDescription with redirect to User:Moresby/ValueDescription
- These pages now using new template:
- Updated seven pages which included {{Fi:ValueDescription}} but did not have
- Fi:Tag:amenity=atm
- Fi:Tag:amenity=baby_hatch
- Fi:Tag:amenity=bank
- Fi:Tag:amenity=bicycle_parking
- Fi:Tag:amenity=bicycle_rental
- Fi:Tag:amenity=bureau_de_change
- Fi:Tag:amenity=car_rental
- Fi:Tag:amenity=car_sharing
- Fi:Tag:amenity=cinema
- Fi:Tag:amenity=courthouse
- Fi:Tag:amenity=crematorium
- Fi:Tag:amenity=embassy
- Fi:Tag:amenity=ferry_terminal
- Fi:Tag:amenity=fire_station
- Fi:Tag:amenity=fountain
- Fi:Tag:amenity=fuel
- Fi:Tag:amenity=library
- Fi:Tag:amenity=nightclub
- Fi:Tag:amenity=police
- Fi:Tag:amenity=prison
- Fi:Tag:amenity=recycling
- Fi:Tag:amenity=telephone
- Fi:Tag:amenity=theatre
- Fi:Tag:amenity=townhall
- Fi:Tag:amenity=veterinary
- Fi:Tag:building=garage
- Fi:Tag:building=garages
- Fi:Tag:highway=crossing
- Fi:Tag:highway=footway
- Fi:Tag:highway=secondary
- Fi:Tag:highway=speed_camera
- Fi:Tag:highway=steps
- Fi:Tag:highway=tertiary
- Fi:Tag:highway=unclassified
- Fi:Tag:leisure=dog_park
- Fi:Tag:leisure=slipway
- Fi:Tag:man_made=wastewater_plant
- Fi:Tag:man_made=watermill
- Fi:Tag:natural=tree
- Fi:Tag:natural=wetland
- Fi:Tag:power=tower
- Fi:Tag:railway=crossing
- Fi:Tag:railway=level_crossing
- Fi:Tag:service=parking_aisle
- Fi:Tag:shop=bakery
- Fi:Tag:shop=bicycle
- Fi:Tag:shop=butcher
- Fi:Tag:shop=car
- Fi:Tag:shop=dry_cleaning
- Fi:Tag:sport=shooting
- Fi:Tag:tourism=hotel
- Fi:Tag:tourism=zoo
- Fi:Tag:waterway=river
- Fi:Tag:waterway=stream
- Replaced Template:NL:KeyDescription with redirect to User:Moresby/KeyDescription
- These pages now using new template:
- NL:Key:cycleway
- NL:Key:building
- NL:Key:amenity
- NL:Key:demolished
- NL:Key:office
- NL:Key:addr
- NL:Key:man_made
- NL:Key:shop
- NL:Key:tourism
- NL:Key:craft
- NL:Key:emergency
- NL:Key:public_transport
- NL:Key:name
- NL:Key:type
- NL:Key:route_master
- NL:Key:colour
- NL:Key:landuse
- NL:Key:military
- NL:Key:natural
- NL:Key:leisure
- NL:Key:fenced
- NL:Key:fence_type
- NL:Key:barrier
- NL:Key:backrest
- NL:Key:bench
- NL:Key:waste
- Stage 3: assuming no showstoppers, replace one or other of {{KeyDescription}} or {{ValueDescription}} with the new template
- {{ValueDescription}} replaced with a redirect to User:Moresby/ValueDescription at around 2014-04-14 21:30 GMT.
- Stage 4: replace the other with the new template
- {{KeyDescription}} replaced with a redirect to User:Moresby/KeyDescription at around 2014-04-17 22:30 GMT.
- reverted by User:Pigsonthewing at around 2014-04-17 23:00 GMT — discussion.
- Extra
url_patternadded, and redirect reinstated at around 2014-04-18 15:35 GMT.
- Stage 5: redirect language templates to User:Moresby/KeyDescription or User:Moresby/ValueDescription as appropriate, identifying any remaining language-specific features and incorporating as appropriate
- Stage 6: update individual description pages to point to {{KeyDescription}} or {{ValueDescription}}, retaining page-specific parameters
Template FR:ValueDescription
Template Template:NL:KeyDescription
Template Template:Uk:ValueDescription
Template Template:RU:KeyDescription
Template Template:Ja:ValueDescription
| Page name | Migrated |
|---|---|
| JA:Tag:amenity=pub | 2014-04-21 18:04:17 GMT |
| JA:Tag:amenity=bar | 2014-04-21 18:04:23 GMT |
Template Template:Fr:KeyDescription
Template Template:It:ValueDescription
Template Template:ES:KeyDescription
Template Template:Fi:ValueDescription
Template Template:IT:KeyDescription
Template Template:RU:ValueDescription
Template Template:FR:KeyDescription
Template Template:ES:ValueDescription
Template Template:El:KeyDescription
| Page name | Migrated |
|---|---|
| El:Key:building:levels | 2014-04-22 17:44:45 GMT |
| El:Key:height | 2014-04-22 17:44:52 GMT |
Template JA:ValueDescription
Template Template:Sv:KeyDescription
| Page name | Migrated |
|---|---|
| Sv:Key:name | 2014-04-22 18:04:02 GMT |
Template Template:DE:ValueDescription
Template Template:Da:ValueDescription
Template Template:Cs:KeyDescription
Template Template:De:ValueDescription
Template JA:KeyDescription
Template Template:Pt:ValueDescription
Template Template:It:KeyDescription
Template Template:Zh-hans:ValueDescription
Template Template:De:KeyDescription
Template Template:NL:ValueDescription
Template Template:Fi:KeyDescription
Template Template:Sv:ValueDescription
Template FR:Template:KeyDescription
| Page name | Migrated |
|---|---|
| FR:Key:overtaking | 2014-04-23 07:35:55 GMT |
Template Template:Pt:KeyDescription
Template Template:Fr:ValueDescription
Template Template:Lt:KeyDescription
| Page name | Migrated |
|---|---|
| Lt:Key:cycleway | 2014-04-23 18:15:13 GMT |
Template Template:Pt-br:KeyDescription
Template Template:FR:ValueDescription
Template Template:Cs:ValueDescription
Template Template:Da:KeyDescription
| Page name | Migrated |
|---|---|
| Da:Key:access | 2014-04-23 20:37:44 GMT |
Template Template:Ar:ValueDescription
| Page name | Migrated |
|---|---|
| Ar:Tag:shop=bakery | 2014-04-23 20:40:05 GMT |
| Ar:Tag:amenity=school | 2014-04-23 20:40:11 GMT |
Template Template:Zh-hans:KeyDescription
Template Template:Uk:KeyDescription
Template Template:Ro:KeyDescription
| Page name | Migrated |
|---|---|
| Ro:Key:amenity | 2014-04-23 21:21:04 GMT |
Template Template:Hu:KeyDescription
Template Template:DE:KeyDescription
Template Template:Ca:KeyDescription
| Page name | Migrated |
|---|---|
| Ca:Key:name | 2014-04-23 21:48:43 GMT |
Template Template:Ar:KeyDescription
| Page name | Migrated |
|---|---|
| Ar:Key:name | 2014-04-23 21:51:24 GMT |
- Stage 7: replace content of {{KeyDescription}} and {{ValueDescription}} with code from User:Moresby/KeyDescription and User:Moresby/ValueDescription
- Stage 8: collect and find appropriate places for documentation and discussion
Discussion
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)
- 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 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)
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)
- 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)
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)
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)
- 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)
- OK, I've made some changes:
- 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)
- Hi, it is getting better, but there are still some things I miss:
- 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)
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)
- 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):
- Thanks! - It looks OK now.
<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)
- I don't think that the content of the
- 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)
Website and URL pattern
It seems we need to continue the discussion from Template_talk:KeyDescription#Website and URL pattern because the fields in question have been carried over to the unified template. Given that a majority had stated their opposition to these highly specialized fields, and Andy did not respond to the objections for two weeks, I think these fields should be removed from this template again unless convincing new arguments are brought forward. --Tordanik 20:11, 18 April 2014 (UTC)
- We should be having any discussions of these useful parameters in a more prominent place than one user's transitive sub-page's talk page; I'll respond at Template_talk:KeyDescription. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:16, 18 April 2014 (UTC)
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)
Formatting of parameters
Hi Moresby, I think you should stop trying to format the parameters in templates by including spaces. I use a different font or editor than you do apparently and therefore it actually looks worse after you add those spaces to have equal signs aligned. I believe that this will be true for others as well. Thanks.Chrabros (talk) 05:33, 23 April 2014 (UTC)
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)
Templates without image parameter
Now that the dust of the big changes has settled, I'd like to bring up the topic of how to handle templates with no image being set. The current behaviour (which was introduced along with the template restructuring) is to show a huge version of the "key" or "key=value" icon. I would prefer if we would just use no image at all in those cases (e.g. abstract things like Key:type). --Tordanik 08:45, 27 June 2014 (UTC)
- The only image I could think of for type is the relation icon. While there are certainly pages without images that could have them, an abstract image or the old way of nagging about it with “No image yet” seems pointless. --Andrew (talk) 08:17, 28 June 2014 (UTC)
Wikidata
There is a discussion on whether/how to keep the recently added wikidata parameter at Template talk:ValueDescription#Wikidata.--Andrew (talk) 12:03, 2 September 2014 (UTC)--Andrew (talk) 12:03, 2 September 2014 (UTC)
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)
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)
- "Wikidata link has nearly no use" is false. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:10, 9 May 2020 (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)
- 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)
- 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)
- "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)
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)
- Ok, I'm going to explain my point of view in some more detail:
- 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)
- 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)
- 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)
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)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 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)
- 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'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’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)
- 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)
- 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}}:
- Link for statuslink parameter (to be kept).
- Change of colour to white to stop an argument, not as a considered change.
- Massive rearrangement of whitespace that broke relation descriptions and makes extensive other changes harder to follow.
- Depopulation of Category:Cs:Czech Documentation.
- Removal of link to source for images.
- To {{KeyDescription}}:
- Low-value fiddling.
- To {{ValueDescription}}:
- Low-value fiddling.
- To {{RelationDescription}}:
- Hurried workround to changes to {{Description}}.
- To {{DescriptionLang}}:
- Additional translations to Japanese (to be kept).
- Ordering by string instead of language (need to consult translators whether good).
- Additional links to Elements across languages + correction in Czech (to be kept).
- To {{StatusLang}}:
- Ordering by string instead of language (need to consult translators whether good).
- Updated translations to French and Czech (to be kept).
- To {{ElementUsageLang}}:
- 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)
- 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)
- What is your view as a Portuguese speaker of the use of
The changes to documentation subpages since January have been (excluding those already reverted):
- To {{Description/doc}}:
- Changes to documentation of status parameter (deserves a separate review).
- Addition of editing warning (to be kept).
- Adjustment of wiki syntax (to be kept).
- To {{KeyDescription/doc}}:
- Tidying of documentation and additional explanations (to be kept).
- Addition of editing warning (to be kept).
- To {{ValueDescription/doc}}:
- Addition of editing warning (to be kept).
- Adjustment of wiki syntax (to be kept).
- To {{RelationDescription/doc}}:
- Adjustment of wiki syntax (to be kept).
- To {{DescriptionLang/doc}}:
- 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)
- Table of translations flipped (columns were languages, now translations).
- To {{StatusLang/doc}}:
- To {{ElementUsageLang/doc}}:
--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)
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)
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)
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)
Support of value only
The values *=construction and *=proposed are used for many keys with the same meaning. Potentially also *=sidewalk (for footway, path, cycleway). Using Template:ValueDescription with key=* and value=construction gives links to Key:* and Tag:*=scheduled which looks not good.
- What would be the best way of using the current templates for *=construction?
- Would another template (e.g. ValueOnlyDescription) be useful?
- What about a new namespace https://wiki.openstreetmap.org/wiki/Value: ?
--Jojo4u (talk) 13:52, 22 May 2016 (UTC)
- Also access=designated and all other access=*.--Jojo4u (talk) 13:54, 17 April 2017 (UTC)
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
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)
- 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
- 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)
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)
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)
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)
Lego strings
I propose changing dropping the {{localised-colon}} from {{DescriptionLang|Status|{{{lang|}}}}}{{localised-colon|lang={{{lang|}}}}} and moving the colons into the status strings. This gives a slightly more optimised template and the opportunity to handle colons differently in some languages. --Andrew (talk) 07:33, 25 June 2019 (UTC)
- This means that
{{DescriptionLang|Status}}returns Status: followed by a space in English and similar equivalents in other languages. --Andrew (talk) 15:08, 30 June 2019 (UTC)
- That sounds reasonable. Alternatively, we could replace {{Localised-colon}} with MediaWiki:Colon-separator or MediaWiki:Metadata-langitem.
{{int:colon-separator}}would be dependent on the current interface language; if we really need to maintain compatibility with |lang =, then we could usemw.messagein a module to get the message in the correct language:mw.message.new("localised-colon"):inLanguage(frame.args.lang). – Minh Nguyễn 💬 22:35, 30 June 2019 (UTC)
- That sounds reasonable. Alternatively, we could replace {{Localised-colon}} with MediaWiki:Colon-separator or MediaWiki:Metadata-langitem.
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)
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)
Recent addition of rendering samples
[User:MalgiK] - What was the reason for these changes: https://wiki.openstreetmap.org/w/index.php?title=Template%3ADescription&type=revision&diff=1930091&oldid=1872970 ? Is it really necessary to have separate rendering samples for nodes, lines and areas? --Jeisenbe (talk) 17:16, 11 December 2019 (UTC)
- The reason is to show different pictures of carto-rendering for objects which have different rendering, depending if these are tagged as a node element or as an area element. You could see cases in this list AreasTab, there are tags which having a symbol as node and symbol+area as area rendering. My initial attempt to tell wiki article readers this information via VD-Box was like these examples (putting two picture under
osmcarto-rendering):- => https://wiki.openstreetmap.org/w/index.php?title=Tag:railway%3Dstation&oldid=1929387
- => https://wiki.openstreetmap.org/w/index.php?title=Tag:leisure%3Ddog_park&oldid=1898576
- both visualizations are not really looking nice, also by showing square-bracket open [[ & square-bracket close ]] characters
- The next attempt was to use the mentioned additional VD-box-parameters, so currently it looks like this:
- This alternative is for user [User:Geozeisig] and me more acceptable, because at least without showing [[ and ]] characters
- There are 2 other talks which belongs a bit to this topic, see here (sorry is in German):
- If you have better idea/ideas i'm happy to hear and see it :-)--MalgiK (talk) 12:10, 12 December 2019 (UTC)
- The reason is to show different pictures of carto-rendering for objects which have different rendering, depending if these are tagged as a node element or as an area element. You could see cases in this list AreasTab, there are tags which having a symbol as node and symbol+area as area rendering. My initial attempt to tell wiki article readers this information via VD-Box was like these examples (putting two picture under
- +1, infobox is for summary and anyway in OSM Carto it is rare that showing all three variants to add any useful info above showing one representative case Mateusz Konieczny (talk) 21:59, 11 December 2019 (UTC)
- One factor which (I believe) hasn't been considered so far is the lack of Taginfo compatibility with the new parameters. Making this field available to Taginfo is the main reason for having it part of the infobox at all. In particular, the goal was to be able to include rendering examples in Taginfo/Taglists, as Map features was using this kind of column and we wouldn't have been able to replace such tables otherwise. If machine-readability isn't a factor, images could just be placed in a gallery in a "Rendering" section on the page, and this would in fact be my suggestion for situations where a single image isn't sufficient. Not only would this easily allow multiple images for Carto plus any explanatory text that's necessary, but it would also allow examples from other renderers and applications to be featured with equal prominence. --Tordanik 16:38, 21 December 2019 (UTC)
- Right, i didn't know, that the parameter
osmcarto-renderingcame via this change in Sept 2016 into the info-box, and that only because of the goal to fill an additional column (title: "Map rendering") for the Taginfo/Taglists tables. [btw1/2] But it seems there are many other parameters implemented at the info-box which all also not used for Taglist computing (e.g.group,requires,implies,combination,seeAlso,status,statuslink,website, and so on). So why not have 3 more (osmcarto-rendering-node,osmcarto-rendering-way,osmcarto-rendering-area) which are not used for Taglists?
For me i like the goal & idea to see and find the rendered icon/colour for each tag on his tag wiki article page on the same defined position. The position at into-box seems perfect, so in other words, in my opinion the rendering data at info-box is fine, even if this wouldn't be used for Taglists. - [btw1] Is there any option to preview wiki-articles changes on any wiki-articles which using these Taglists without this error "LOADING TAG LIST... (If you do not see this tag list, you need to enable Javascript)"?
- [btw2] How/where can we change the column title text from "Map rendering" to maybe "carto-Rendering" and set an additional link to Standard tile layer? --MalgiK (talk) 08:50, 4 January 2020 (UTC)
- Can we please revert the changes to the template? It appears that this change is not necessary and will cause problems with Taginfo. --Jeisenbe (talk)`
- How would you show via info-box that e.g. for leisure=dog_park the
is used for 
node objects and 
is used for 
area objects. What is the problem with Taginfo in detail? --MalgiK (talk) 19:30, 18 February 2020 (UTC)
- The leisure=dog_park rendering needs to be fixed, we have an open issue about that. It doesn't make sense for us to use a different icon for the area and a node. But this can easily be shown by adding an image in the main text of the wiki page. It doesn't need to be in the ValueDescription or KeyDescription box, because these are meant to be machine-readable tags for use by Taginfo and editor apps, where one sample is sufficient. --Jeisenbe (talk) 12:12, 19 February 2020 (UTC)
- It's not only a question for tag leisure=dog_park, e.g. also for tag highway=platform (the
is used for 
way objects and 
is used for area objects). Actually i'm not so happy about to illustrate the rendering for some tags in the info-box and for some other tags in the main article text. I still not complete understand, why this version to show different pictures in the info-box, could/should not be possible. Btw how is the current rendering for hedges? I remember there was a render change, but i did not check in detail, are there also different renderings for lines and areas? --MalgiK (talk) 15:13, 20 February 2020 (UTC)
- "Openstreetmap Carto" is just one map style. While it is influencial, a single rendering sample for each feature is more than enough. If we are going to include more than one rendering sample, it would be much better to show a sample the Humanitarian (HDM) layer or one of the other map layers on openstreetmap.org rather than showing minor differences in the rendering of areas vs ways vs nodes in one style. (And yes, hedge areas and ways now have the same rendering, so that is one less issue). --Jeisenbe (talk) 05:32, 21 February 2020 (UTC)
- It's not only a question for tag leisure=dog_park, e.g. also for tag highway=platform (the
- The leisure=dog_park rendering needs to be fixed, we have an open issue about that. It doesn't make sense for us to use a different icon for the area and a node. But this can easily be shown by adding an image in the main text of the wiki page. It doesn't need to be in the ValueDescription or KeyDescription box, because these are meant to be machine-readable tags for use by Taginfo and editor apps, where one sample is sufficient. --Jeisenbe (talk) 12:12, 19 February 2020 (UTC)
- How would you show via info-box that e.g. for leisure=dog_park the
- Can we please revert the changes to the template? It appears that this change is not necessary and will cause problems with Taginfo. --Jeisenbe (talk)`
- Right, i didn't know, that the parameter
- One factor which (I believe) hasn't been considered so far is the lack of Taginfo compatibility with the new parameters. Making this field available to Taginfo is the main reason for having it part of the infobox at all. In particular, the goal was to be able to include rendering examples in Taginfo/Taglists, as Map features was using this kind of column and we wouldn't have been able to replace such tables otherwise. If machine-readability isn't a factor, images could just be placed in a gallery in a "Rendering" section on the page, and this would in fact be my suggestion for situations where a single image isn't sufficient. Not only would this easily allow multiple images for Carto plus any explanatory text that's necessary, but it would also allow examples from other renderers and applications to be featured with equal prominence. --Tordanik 16:38, 21 December 2019 (UTC)
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 --MalgiK (talk) 13:38, 20 February 2020 (UTC)
Remove wikidata from this template
I plan to remove the wikidata lines from this template, per discussion here (above: https://wiki.openstreetmap.org/wiki/Template_talk:Description#Wikidata and https://wiki.openstreetmap.org/wiki/Template_talk:Description#Wikidata_link) and on the related ValueDescription template (see https://wiki.openstreetmap.org/wiki/Template_talk:ValueDescription#Wikidata) and on the Talk mailing list (Starting at https://lists.openstreetmap.org/pipermail/talk/2020-May/084637.html). --Jeisenbe (talk) 21:43, 4 May 2020 (UTC)
- This has been done now, seeing there were no objections. --Jeisenbe (talk) 21:34, 8 May 2020 (UTC)
- If you really think there were no objections in the linked discussions you need to re-read them. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:14, 9 May 2020 (UTC)
- Are you sure that you posted what you wanted to post? "seeing there were no objections." is clearly untrue. See linked https://wiki.openstreetmap.org/wiki/Template_talk:Description#Wikidata_link with "Hiding values is harmful; it leads to people not spotting errors." Mateusz Konieczny (talk) 18:59, 9 May 2020 (UTC)
- To be clear, I fully support removal of this parameter. It still remains unclear why we would want such prominent links to Wikidata on OSM Wiki. Comment of edit was OK and without mistake like here in the discussion. Mateusz Konieczny (talk) 19:07, 9 May 2020 (UTC)
- The reasons why have been explained to you previously. Whether you don't understand them or don't like them does not make them less real. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:15, 9 May 2020 (UTC)
- "explained to you" - this is untrue. Given claims appeared to me extremely weak, I asked for clarification/conformation that was never made. Primary claimed use is bizarre case of someone frequently using Wikidata to query data about matching object, but not using data items and doing it manually based on infobox links. Maybe it is something rarely done by people, but it is not something that is highly important to describe OSM tags. Given extremely low data quality of links it appears that this is not used for anything. And putting this useless link above taginfo statistics is ridiculous. Mateusz Konieczny (talk) 23:59, 9 May 2020 (UTC)
- Your claim that explanations have not been given is undermined by the fact that you have replied to those explanations Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:03, 10 May 2020 (UTC)
- Explanations were weak, incomplete and unclear. To repeat myself "I asked for clarification/conformation that was never made". Some comments were made, but were insufficient to explain anything. Mateusz Konieczny (talk) 15:11, 10 May 2020 (UTC)
- 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)
- "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)
- 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)
- 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)
- 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)
- 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)
- 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)