Template talk:Description

From OpenStreetMap Wiki
Jump to: navigation, search

User:Moresby/KeyDescription and User:Moresby/ValueDescription are reimplementations of the various {{KeyDescription}} and {{ValueDescription}} templates used widely across this wiki to document tag usage.

Rationale for this new template

Key and value description templates
Language Key description template Value description template
ar {{ar:KeyDescription}} {{ar:ValueDescription}}
ca {{ca:KeyDescription}} {{ca:ValueDescription}}
cs {{cs:KeyDescription}} {{cs:ValueDescription}}
da {{da:KeyDescription}} {{da:ValueDescription}}
de {{DE:KeyDescription}} {{de:ValueDescription}}
en {{KeyDescription}} {{ValueDescription}}
es {{ES:KeyDescription}} {{ES:ValueDescription}}
fi {{fi:KeyDescription}} {{fi:ValueDescription}}
fr {{FR:KeyDescription}} {{fr:ValueDescription}}
hu {{hu:KeyDescription}} {{hu:ValueDescription}}
it {{IT:KeyDescription}} {{it:ValueDescription}}
ja {{JA:KeyDescription}} {{ja:ValueDescription}}
lt {{lt:KeyDescription}} {{lt:ValueDescription}}
nl {{NL:KeyDescription}} {{NL:ValueDescription}}
pl {{pl:KeyDescription}} {{pl:ValueDescription}}
pt {{pt:KeyDescription}} {{pt:ValueDescription}}
ro {{ro:KeyDescription}} {{ro:ValueDescription}}
ru {{RU:KeyDescription}} {{RU:ValueDescription}}
sv {{sv:KeyDescription}} {{sv:ValueDescription}}
uk {{uk:KeyDescription}} {{uk:ValueDescription}}
zh-hans {{zh-hans:KeyDescription}} {{zh-hans:ValueDescription}}

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.


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


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 None yet.jpg to Osm element key.svg or Osm element tag.svg 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
| 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}}
+/-Public-images-osm logo.svg highway=trunk

One example for highway=trunk


Important roads that aren't motorways.

Used on these elements

should not be used on nodes may be used on ways should not be used on areas use on relations unspecified

Useful combination

Undefined Status: Undefined

Public-images-osm logo.svg highway = trunk
Dscf0444 600.jpg
Important roads that aren't motorways.
Used on these elements
should not be used on nodesmay be used on waysshould not be used on areasuse on relations unspecified
Useful combination
Status: Unspecified

| description=Ein Geschäft für Autoteile, Autozubehör, Motoröl usw.



Ein Geschäft für Autoteile, Autozubehör, Motoröl usw.


Undefined Status: Undefined Hilfe

Public-images-osm logo.svg Value description Bitte hilf dies in deine Sprache zu übersetzen!
Osm element tag.svg
Ein Geschäft für Autoteile, Autozubehör, Motoröl usw.
Für diese Elemente
use on nodes unspecified use on ways unspecified use on areas unspecified use on relations unspecified 
Status: Unbestimmt

| 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
+/- disused

One example for disused


Namespace for features that have fallen into disuse, but which are still useful for navigation and visible in the landscape.



Used on these elements

may be used on nodes may be used on ways may be used on areas use on relations unspecified

See also



In use Status: In Use

Public-images-osm logo.svg disused
Namespace for features that have fallen into disuse, but which are still useful for navigation and visible in the landscape.
Group: Lifecycle
Used on these elements
may be used on nodesmay be used on waysmay be used on areasuse on relations unspecified
See also


Status: In use

|key         = cuisine
|image       = Image:Burger 1 bg 080206.jpg
|description = Для описания типа еды предлагаемой в ресторане или кафе
|group       = cuisine
|onNode      = yes
|onWay       = no
|onArea      = yes
|onRelation  = no
|lang        = en
* {{Template:RU:Tag|amenity|restaurant}}
* {{Template:Tag|takeaway||yes/no}}
* {{Template:Tag|diet}}
+/- cuisine

Один из примеров cuisine


Для описания типа еды предлагаемой в ресторане или кафе

Относится к группе


Назначается на эти элементы: Справка
точки можно отмечать этим тегомлинии не принято отмечать этим тегомполигоны можно отмечать этим тегомотношения не принято отмечать этим тегом
Полезные сочетания
Статистика применения

Не указан

Public-images-osm logo.svg cuisine
Burger and fries (1).jpg
Для описания типа еды предлагаемой в ресторане или кафе
Группа: Cuisine
Назначается на следующие элементы
точки можно отмечать этим тегомлинии не принято отмечать этим тегомполигоны можно отмечать этим тегомотношения не принято отмечать этим тегом
Задокументированные значения: 4
Уточняющие теги
Статус: Не указан

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.

Key and value description templates

Language Key description template Migrated Value description template Migrated
ar {{ar:KeyDescription}} 2014-04-19 14:32 GMT {{ar:ValueDescription}} 2014-04-19 14:03 GMT
ca {{ca:KeyDescription}} 2014-04-19 14:38 GMT {{ca:ValueDescription}} -
cs {{cs:KeyDescription}} 2014-04-19 12:43 GMT {{cs:ValueDescription}} 2014-04-19 13:27 GMT
{{cz:KeyDescription}} - {{cz:ValueDescription}} -
{{CS:KeyDescription}} - {{CS:ValueDescription}} -
da {{da:KeyDescription}} 2014-04-19 13:20 GMT {{da:ValueDescription}} 2014-04-19 11:28 GMT
de {{DE:KeyDescription}} 2014-04-19 12:37 GMT {{DE:ValueDescription}} 2014-04-19 08:00 GMT
{{de:KeyDescription}} 2014-04-19 12:38 GMT {{de:ValueDescription}} 2014-04-19 07:57 GMT
el {{el:KeyDescription}} 2014-04-20 18:57 GMT {{el:ValueDescription}} -
en {{KeyDescription}} 2014-04-18 15:35 GMT {{ValueDescription}} 2014-04-14 21:33 GMT
{{KeyDescription no translation}} 2014-04-22 18:18 GMT {{ValueDescription no translation}} 2014-04-22 18:19 GMT
es {{ES:KeyDescription}} 2014-04-19 13:13 GMT {{ES:ValueDescription}} 2014-04-19 11:18 GMT
{{es:KeyDescription}} 2014-04-19 13:14 GMT {{es:ValueDescription}} -
fi {{fi:KeyDescription}} 2014-04-19 13:01 GMT {{fi:ValueDescription}} 2014-04-09 22:00 GMT
fr {{FR:KeyDescription}} 2014-04-19 12:29 GMT {{FR:ValueDescription}} 2014-04-19 09:20 GMT
{{fr:KeyDescription}} 2014-04-19 12:30 GMT {{fr:ValueDescription}} 2014-04-19 09:18 GMT
FR:KeyDescription - FR:ValueDescription 2014-04-19 16:27 GMT
FR:Template:KeyDescription 2014-04-22 18:10 GMT FR:Template:ValueDescription -
hu {{hu:KeyDescription}} 2014-04-19 13:43 GMT {{hu:ValueDescription}} -
it {{IT:KeyDescription}} 2014-04-18 21:26 GMT {{IT:ValueDescription}} -
{{it:KeyDescription}} 2014-04-18 21:32 GMT {{it:ValueDescription}} 2014-04-19 11:41 GMT
ja {{JA:KeyDescription}} 2014-04-19 11:08 GMT {{JA:ValueDescription}} -
{{ja:KeyDescription}} 2014-04-19 11:09 GMT {{ja:ValueDescription}} 2014-04-18 21:40 GMT
JA:KeyDescription 2014-04-19 11:12 GMT JA:ValueDescription 2014-04-18 21:42 GMT
lt {{lt:KeyDescription}} 2014-04-19 14:40 GMT {{lt:ValueDescription}} -
nl {{NL:KeyDescription}} 2014-04-12 16:53 GMT {{NL:ValueDescription}} 2014-04-19 09:43 GMT
pl {{pl:KeyDescription}} - {{pl:ValueDescription}} -
pt {{pt:KeyDescription}} 2014-04-19 13:32 GMT {{pt:ValueDescription}} 2014-04-19 13:22 GMT
pt-br {{pt-br:KeyDescription}} 2014-04-20 16:41 GMT {{pt-br:ValueDescription}} 2014-04-20 18:56 GMT
ro {{ro:KeyDescription}} 2014-04-19 14:42 GMT {{ro:ValueDescription}} -
ru {{RU:KeyDescription}} 2014-04-19 08:54 GMT {{RU:ValueDescription}} 2014-04-19 11:51 GMT
RU:Template:KeyDescription 2014-04-22 18:14 GMT RU:Template:ValueDescription 2014-04-22 18:16 GMT
sv {{sv:KeyDescription}} 2014-04-19 14:48 GMT {{sv:ValueDescription}} 2014-04-19 13:51 GMT
uk {{uk:KeyDescription}} 2014-04-19 13:09 GMT {{uk:ValueDescription}} 2014-04-19 09:56 GMT
zh-hans {{zh-hans:KeyDescription}} 2014-04-19 13:46 GMT {{zh-hans:ValueDescription}} 2014-04-19 13:59 GMT
Key and value description templates
Language Key description template Migrated Value description template Migrated
ar {{ar:KeyDescription}} yes {{ar:ValueDescription}} yes
ca {{ca:KeyDescription}} yes {{ca:ValueDescription}} .
cs {{cs:KeyDescription}} yes {{cs:ValueDescription}} yes
da {{da:KeyDescription}} yes {{da:ValueDescription}} yes
de {{DE:KeyDescription}} yes {{DE:ValueDescription}} yes
{{de:KeyDescription}} yes {{de:ValueDescription}} yes
el {{el:KeyDescription}} yes {{el:ValueDescription}} .
en {{KeyDescription}} n/a {{ValueDescription}} n/a
{{KeyDescription no translation}} none {{ValueDescription no translation}} none
es {{ES:KeyDescription}} yes {{ES:ValueDescription}} yes
{{es:KeyDescription}} none {{es:ValueDescription}} .
fi {{fi:KeyDescription}} yes {{fi:ValueDescription}} yes
fr {{FR:KeyDescription}} yes {{FR:ValueDescription}} yes
{{fr:KeyDescription}} yes {{fr:ValueDescription}} yes
FR:KeyDescription . FR:ValueDescription yes
FR:Template:KeyDescription yes FR:Template:ValueDescription .
hu {{hu:KeyDescription}} yes {{hu:ValueDescription}} .
it {{IT:KeyDescription}} yes {{IT:ValueDescription}} .
{{it:KeyDescription}} yes {{it:ValueDescription}} yes
ja {{JA:KeyDescription}} none {{JA:ValueDescription}} .
{{ja:KeyDescription}} none {{ja:ValueDescription}} yes
JA:KeyDescription yes JA:ValueDescription yes
lt {{lt:KeyDescription}} yes {{lt:ValueDescription}} .
nl {{NL:KeyDescription}} yes {{NL:ValueDescription}} yes
pl {{pl:KeyDescription}} . {{pl:ValueDescription}} .
pt {{pt:KeyDescription}} yes {{pt:ValueDescription}} yes
pt-br {{pt-br:KeyDescription}} yes {{pt-br:ValueDescription}} none
ro {{ro:KeyDescription}} yes {{ro:ValueDescription}} .
ru {{RU:KeyDescription}} yes {{RU:ValueDescription}} yes
RU:Template:KeyDescription none RU:Template:ValueDescription none
sv {{sv:KeyDescription}} yes {{sv:ValueDescription}} yes
uk {{uk:KeyDescription}} yes {{uk:ValueDescription}} yes
zh-hans {{zh-hans:KeyDescription}} yes {{zh-hans:ValueDescription}} yes


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)

Language-specific tool links

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

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

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)
Hmm, hope that I understood correctly, that I would use your template for Czech pages and it will contain the Czech translations in itself. Or am I wrong and I would have to use your template, copy it and translate it to standalon Czech version? Chrabros (talk) 08:31, 7 April 2014 (UTC)
If I've got it right, I'll change the current Czech template to call the new one, and everything should simply drop into place, with Czech translations of the headings in the boxes, and so on. All I'll need from you is some reassurance that the language is OK in context - the rest I should be able to work out. Like any other change, it can be undone at any time, of course, so there will be nothing which is irreversible. It's just that a second opinion from a Czech native speaker will make me less worried. :-) Moresby (talk) 09:24, 7 April 2014 (UTC)
Here are current problems with your template as I see them:
  • the Czech categories are gone (I had Cs:Značky podle klíče, Cs:Značky podle hodnoty, Cs:Klíče:amenity, Czech Documentation)
  • links and descriptions of Elements Icons were Czech, they are English now ("Can be used on Node", link to Node page)
  • Tools are very wrong - I had two Taginfos (one worldwide and one for Czech Republic only) then I had another selection of some interesting countries. I think it is important for every country to choose which other countries they want to see here.
  • Overpass turbo icon is gone and it was a nice one. ;-)
  • Why is there the ugly green checkmark? File:Yes check.svg

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

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


This discussion was moved from User talk:Moresby.

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

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

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)
Actually it's "De nada" haha (it's the second translation that google suggests). "Seja bem-vindo" mean something like "you are welcome to this place". --Jgpacker (talk) 20:51, 23 April 2014 (UTC)
You see, this is why I leave it to the experts. :-) Moresby (talk) 20:52, 23 April 2014 (UTC)

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)


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


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

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

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

The shocking behaviour begins with your edit (1). Please vote for your changes only after all (lists.openstreetmap.org). We will not argue. And we do not need editwar in an important template! In addition caused your extension errors. Read in DE --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)

Edits since January 2015, consider reversion

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

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

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

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

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

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

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

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

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

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

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)

I removed them.--Jojo4u (talk) 19:10, 22 October 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.

  1. What would be the best way of using the current templates for *=construction?
  2. Would another template (e.g. ValueOnlyDescription) be useful?
  3. What about a new namespace https://wiki.openstreetmap.org/wiki/Value: ?

--Jojo4u (talk) 13:52, 22 May 2016 (UTC)

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