Template talk:ValueDescription

From OpenStreetMap Wiki
Jump to: navigation, search

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

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

Translating a existing page

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

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

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


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

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

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

Any thoughts/objections?

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

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


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

If we support the parameter there, it should be supported here, too. But first it would be advisable to actually document the new wikidata parameter properly. Currently an explanation is missing from the template description, only its existence is noted. And while I find the idea interesting in general, I would also like to see some examples on how to use it (and how not to use it). I don't think this is self-evident. (I also dislike the complete lack of discussion preceding its introduction, by the way.) --Tordanik 01:49, 30 August 2014 (UTC)
It’s been added to Key:bridge. The icon for missing translations can be fixed if it’s worth keeping. I can’t say I’m convinced yet.--Andrew (talk) 08:04, 30 August 2014 (UTC)
Indeed. That example already points to a problem: While it is sometimes possible to state that all OSM elements with that tag are an instance of some Wikidata item, it is not possible in other situations. For example, roads with bridge=yes crossing a man_made=bridge are not instances of "bridge". Furthermore, a lot of OSM tags don't represent an instance relationship with some class of objects at all, but are properties instead. So I doubt that mapping Wikidata onto OSM tags in that manner is feasible. --Tordanik 21:47, 1 September 2014 (UTC)
So far I do not see any new value of this new wikidata feature. Maybe someone could try to explain its purpose in better example than is Key:bridge. Chrabros (talk) 07:39, 3 September 2014 (UTC)

Categorisation Change

I changed

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


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

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

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

seeAlso Change

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

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


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

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

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

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

Revert of new images

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

Closed way icon

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

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

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

native_value and native_key parameters

We have more and more active people in the mapping who do not speak English.
I suggest adding a parameter to the template for the key and value, such as native_key and native_value. This will allow us to search for the correct key in the user's language.
I'm not sure whether it is possible to write a template for "Category" that can automatically create a list of tags in the user's language, based on these new parameters. --Władysław Komorek (talk) 11:30, 16 March 2014 (UTC)

It would be misleading to suggest that tags are language-dependent. But there are ways to make a word in the native language available to search: You could either use the word in the translated page content, or add a list of RelatedTerm entries at the bottom of the page, containing all synonyms for the object in the native language. --Tordanik 13:58, 16 March 2014 (UTC)
But do not give it to the user, especially the novices, the list of available tags in his language. Create an additional category to the list of tags in the language in no way interferes with the use of the existing categories, but minimize incorrect tagging and show other possibilities for tagging people do not understand the English language.
One of the biggest problems in OSM is a misunderstanding of the importance of individual tags and their improper use. Google Translate does not give a correct translation. --Władysław Komorek (talk) 15:09, 16 March 2014 (UTC)
Wouldn't the translated version of Map Features be much better suited for newbies? Alternatively, you could work on Pl:How to map a; that page is like a dictionary that gives translations from words of your native language into tags. --Tordanik 18:23, 16 March 2014 (UTC)
We have translated the "Map Features" long enough and still have the problem with improper tagging. Nothing has improved. You wrote "Pl:How to map a, that page is like a dictionary", but it is not a dictionary and needs to be written and continuously updated.
Category is the easiest way to automatically creating the current list of translated tags.
Based on the discussion on OpenStreetMap Forum in Polish, new users are very unhappy with the lack of a list of tag names, understandable in their language. Most people are looking for the information based on Wikipedia, where they have categories in their native language. To use the search he needs to know, in advance, a specific tag name. Search of intrinsic tag is too time-consuming and discouraging them to continue mapping. That's why most new users only focused on adding a few POI. --Władysław Komorek (talk) 20:53, 16 March 2014 (UTC)
Perhaps I simply misunderstand what you are trying to do. But to me it looks as if you are trying to solve the following problem: A user wants to tag an object. He knows what such an object is called in their native language. He now wants to find out the tag for it.
But that problem can be solved with some of the suggestions I made above. If you add the word as a RelatedTerm to the page, for example, then the page shows up in the results when the user types the word into the search field. --Tordanik 22:09, 16 March 2014 (UTC)
I already have it. If you open a Polish tag, you'll see in a Polish template for ValueDescription or KeyDescription, equivalent to the key name and value name in the Polish language.
But this is not enough for the Polish newbies. Remember that often the same object can have different names. A similar problem, for example, have users in the U.S., when they are looking for a tag for the road and do not know that the tag for the road is called "highway". This is a big difference between seeking unspecified name and picking a name from the list. --Władysław Komorek (talk) 00:05, 17 March 2014 (UTC)

Reimplementation of KeyDescription and ValueDescription templates

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

Link to "other language discussion sections"

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

status=inuse vs status=defacto

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


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

Edits since January 2015, consider reversion

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

Used on these elements link node

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

Should group name be added a language prefix?

In October 2015, this template has modified; a category name from 'group' is now automatically added a language prefix from 'lang' value. But this has caused another trouble.
For example, the page 'JA:Tag:railway=halt' already has a prefixed group name ('JA:鉄道'). So the category name has become 'JA:JA:鉄道' by adding language prefix automatically.
It can resolve if I change the group name to '鉄道', but it will cause another trouble; if a localized group name has same name to English version, the localized version of category Key descriptions for group "XXX" (created by Template:DescriptionCategories) can't exist independently because it duplicates with the English version.

There are two methods to avoid this trouble:

  1. The all localized group names should be added language prefix, and cancel to add language prefix automatically (by this template).
  2. Modify Template:DescriptionCategories to add language prefix to category name automatically, such as Key descriptions for group "ll:XXX". The all prefixed group names must be modified.

How should we resolve it? --Mfuji (talk) 16:56, 26 October 2015 (UTC)

Group names should not have any prefix. The categorization however is partly broken in languiages other than English as the stan dard template currently does not imply any language prefix for the category name. There are works to do to separate the localized group name and the category name (whose default is the group name, but still not necessarily translated).
There are many "groups" not working properly for sorting features,; and many red links there for missing categories or categories with mixed/random contents.
Only a few groups/feature are currently working almost properly but there are still issues before it can work completely and the solution applied on other groups.
This is work in progress (complicated by the fact that the Feature template has also some localized variants not working exactly like the English one (because the Engliush one is also defective and still ignores how to completely manage translations). — Verdy_p (talk) 12:50, 28 October 2015 (UTC)
In summary: for parameter group=*, just use a unprefixed feature name which will be displayed as is by the template (you can temporarily leave this name in English, but you can translate it to Japanese (don't forget to set lang=ja in the template): if you translate the term, the category translated to Japanese will be "Category:JA:<translated group name in Japanese>". When this category exists, the article will be sorted there.
If you have still not created the category, don't translated the group name (leave it in English), but you can still use lang=ja (the template will first look for "Category:JA:<untranslated group name in English>", then for "Category:<untranslated group name in English>" to sort your Japanese article "JA:<article name in English or Japanese>").
A few groups are being converted to sort them by language. A priori there's no longer need to use a localized version of "Template:ValueDescription" (which still uses the lang=* parameter, but soon you'll no longer even need the lang=* parameter as the language code will be autodetected for the article page name including the template).
Hope this helps. — Verdy_p (talk) 14:02, 28 October 2015 (UTC)
Group names are used in not only "Category:LL:<group name>" but for example key description's category as Key descriptions for group "<group name>" (without language prefix). Isn't it possible that multiple languages have (localized) group names accidentally and in conflict between category names of Key description? (This problem is, however, irrelevant to Japanese...) --Mfuji (talk) 17:37, 28 October 2015 (UTC)
Category:Key descriptions for group "<group name>" do not support any kind of classification of languages for now. All is mixed, and in fact most group names do not have therir own categories even in English. This scheme was added some time ago without any consideration about how it should be classified. I've not attempted to convert them with the languages bar, and prefixes compatible with Template:Langcode. In fact the scheme is not fixable for now, and I don't care much about them. For now it only works for English-only pages. There's a solution to develop, but if we keep that name in English, for other languages it will become Category:<Lang:><translation of:Key descriptions for group> "<group name>" and quoted group names will also be translated. Later it some categories will need to be merged (using soft-redirection templates like other translatable categories)
Note: I do not intend to translate the (technical) **tag** names, but "group names" / "feature names" (in mostly the same naming space as some groups are also isolated features) are not tags and are translatable.
A few groups have started to be translated in their categories (Sports, and Buildings), I using only these to finalize the translation scheme before going further for other groups. The problem is to manage the many legacy templates that have been translated using their own local schemes for specific languages (but that also don't work fully), without breaking all. There's a lot of cleanup work to do to collect everything and get the expected navigation. But with what I did, it cannot be worse than what there's now which is incoherent everywhere and full of red links for lots of missing categories or orphan categories. — Verdy_p (talk) 20:56, 28 October 2015 (UTC)
About your example category, you can look at what I did, but I've still not scanned all languages. It should be OK however for Japanese.
If you still have doubts, about what to do, use English only group names for now (even if this populates categories in mixed languages), they will be translated later. — Verdy_p (talk) 20:58, 28 October 2015 (UTC)
I personally never liked the group attribute exactly because it seems to have been added on a whim to the template, without a good way to use it. Besides this problem you mentioned, there are tags that don't have a well-defined group or belong to multiple groups. I think this parameters shouldn't be used at all, much less add a category. I remember that recently some users went around removing explicit categories from pages, "forcing" the use of this parameter (I don't think they did this out of bad faith, but a previous discussion would have been helpful). --Jgpacker (talk) 23:54, 28 October 2015 (UTC)
I see. I agree if it won't be needed to re-add namespace to group names. I also think the category name Key descriptions for group "<group name>" should be internationalized.
I also think that the group attribute isn't needed, because category can be used instead of it and more flexible. It is problematic (e.g. we can't use multiple group, and it may cause a problem I said), although there is only few benefit. I think it is better if important categories can be enumerated in the info box, instead of groups, then it will become much simpler and flexible. --Mfuji (talk) 11:37, 30 October 2015 (UTC)
I also agree that "groups" were designed only to refer to the name of main subcategories in the "Features" categories. For me they are just a few selected feature names (all translatable independantly of the technical set of tag, i.e. keys/values, used to implement them and that remain preferably in British English).
The bad thing about those "group=*" parameters is that they force the automatic inclusion in some categories not correctly designed an in fact never discussed. It is hard to work with all those Category:<Lang:>Key descriptions for group "<group name>" automatically generated. I would personnally only keep the category names based on the British English key names. But sorting features via the template is a bad idea, and it has in fact never worked correctly the way this was done, and it is not maintainable). — Verdy_p (talk) 13:07, 30 October 2015 (UTC)

Hi, I think, the "group categorisation" piece of code should be removed altogether from this template:

  • "because it seems to have been added on a whim to the template" I totally agree.
  • There is now a more flexible way to add tags to group-specific categories via Template:DescriptionCategories if you do want this kind of categorisation.
  • It doesn't seem to be very widely used: The subcategories of all the categories in "Category:Features/translations" contain a total of exactly 600 pages containing "Tag:" in their title.
The most prominent namespace is Pl:, totalling 280 pages. However, in the total Pl: namespace, only 36 Tag: pages use this template, the others still using Pl:ValueDescription -> no change.
The other two main users are JA: and Cs: at 110 pages each. Cs: is already using Template:DescriptionCategories for that, which means they don't need this code too.
JA: could be enabled in Template:DescriptionCategories to continue pointing to Category:JA:<Group> if wished. Mfuji, what do you think?

Cheers, Charel (talk) 21:31, 29 April 2016 (UTC)

The order of Implies and Useful combination

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

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

Relation multipolygon and onRelation=no?

Discussion moved from Talk:Wiki

Hello, there is a debate (e.g. here) about whether a feature mapped as area will get onRelation=no or onRelation=yes. I had the impression, backed by many wiki pages, that multipolygon relations are an exception and are considered to be just areas. Therefore when a feature can exist as area or multipolygyon relation it gets onArea=yes and onRelation=no.

But user VerdyP claims that we have to set onArea=yes and onRelation=yes. I find this clumsy as multipolygon relations are areas and if we accept this idea then onArea=yes will imply onRelation=yes all the time so onRelation meaning would be not so clear any more.

Could you please state your opinion here?


Chrabroš (talk) 12:28, 14 May 2017 (UTC)

It has been the assumption for as long as I have been involved that onRelation, like onWay, specifically relates to relations that are not areas; that is the whole point of having a separate onArea flag. --Andrew (talk) 20:57, 15 May 2017 (UTC)
I agree with you that multipolygons fall under onArea, not onRelation. That convention is also documented on Template:ValueDescription, so I'm surprised that Verdy p isn't aware of it. --Tordanik 13:40, 21 May 2017 (UTC)
When and where was this agreed ? There has just been some proposals but no discussion anywhere, and many topics use onRelation=yes (including external tools) that do not have this subtle distinction. And I've seen people changing multipolyugon relations into very complex areas (single closed way) because their validator complained about this, and thinking it was invalid to have inner rings for holes and they dropped them, or removed a multipolygon made of several outser areas and replacing them by tagging multiple areas (closed ways) instead, meaning that they duplicated the same feature with two distinct very close locations such as a couple of buildings. — Verdy_p (talk) 17:21, 21 May 2017 (UTC)
Note also that you insist on this, then the icon for relations should be completely dropped everywhere (including for boundaries, and as well for turn restrictions as their real geometry is an oriented line even if it includes an optional via node). We have conflicting interpretations between the OSM representation (used by all external tools) and the effective geometry (which is very fuzzy, as almost all features could become a node, a line or a surface and there's no need to prohibit them). The definition on OSM of an area is a single polygon forming a single non-intersecting ring, it does not include multipolygons with holes or that at not fully connected and have several outer rings.
Nothing was really decided, someone jhust commented his opinion in an informal proposal that was never decided/voted. — Verdy_p (talk) 17:27, 21 May 2017 (UTC)