Template talk:PossibleSynonym

From OpenStreetMap Wiki
Jump to: navigation, search

Not a good idea

I believe this is not an effective way of presenting tagging mistakes: These mistakes are often so rare that there is almost zero chance that I will find one in my area after clicking the Overpass Turbo link. Because people usually edit within a certain "home area", it is a lot more helpful to present all error types in an area, rather than one error type everywhere. That's why we should add them to OSMI, Keepright or the JOSM Validator instead of wiki pages. --Tordanik 08:13, 10 September 2014 (UTC)

I actually agree, but I thought these messages spread around the wiki were hard to modify (too many), were getting out of control (being translated to other languages) and I didn't want to throw away the work AndiG88 did to research those (and I understand you don't intend to throw it away either). I'm not so fond of this approach to pointing out errors, I just wanted to make it more manageable. Feel free to modify this template or the pages that contain it however you want. --Jgpacker (talk) 12:50, 10 September 2014 (UTC)
Yes, I really wish AndiG88 had approached this differently, and I'm not a fan of these additions to tag documentation pages. But I don't have the energy to do it the right way, and reverting all these pages feels destructive. I understand you are just making things easier to maintain, and that's ok with me. I just hope it doesn't encourage more people adding entries like that. --Tordanik 20:59, 10 September 2014 (UTC)
Not sure if it would help, but perhaps we shouldn't link to overpass at all in this template. --Jgpacker (talk) 21:40, 10 September 2014 (UTC)
Wouldn't that just reduce the small benefits of these wiki entries even further? I'm not seeing the benefits here. --Tordanik 17:28, 17 September 2014 (UTC)
Removing the overpass link might reduce the chance of mass edits that could be caused by this template while it's here --Jgpacker (talk) 17:39, 17 September 2014 (UTC)

The look has changed

The look has changed, but look at this lock=*, amenity=townhall, foot=* ... It does not look quite normal.--geozeisig (talk) 05:56, 22 October 2017 (UTC)

yes this is in a pale red box to group correctly the description data and warning that is indepenant of the tag described on the rest of the description page.
there's some quirk to avoid the included "iframe" to get over the standard infobox on the right or possible image thumbs for tyhe rest of the article (this is why the box width has to be limited to not cover that part. The grouoing box avoids confusions and makes clear that this is not a recommanded tagging described in the rest of the article
unfortunately the iframe used (with the wiki extension is not properly encoded, it has to be embeddd in an enclosing div. I have looked at variuous solutions to avoid the mix, but there's still some problems with this iframe (not encoded in wiki code but in custom HTML code encoded by the extension; that Wiki extension needs fixes to be cleaner but for now it's difficult to isolate it clearly: it should be just an inline iframe with no separating paragrap or spacing but the HTML comments inserted there anre not properly placed).
I tested several ways to isolate that iframe correctly on multiple pages where it was already broken. I may need to look for more. And we should then fix that wiki extension for Taginfo.
Note that this template already generates a block it cannot be used in bulleted lists, but it is easy to fix in pages (see what I did in lock=*)
I also removed the "clear" inside the red box at its bottom, because it has the undesired effect of increasing the height to the same bottom position of an infobox extending to the right (this should not occur given the isolation by the outer "div" which is relative, but the iframe has a side effect as its height is variable (depending if Taginfo has data to display or not), so I used an explicit height for the outer red box to include its maximum vertical extension (so that th Taginfo remains within that box and won't collide with the rest of the article, after this template). I tested a lot of pages but not the few ones you cite above that should be OK now. — Verdy_p (talk) 15:37, 22 October 2017 (UTC)

Why red?

Why it is redddish? It makes it the most noticeable part of wiki page for no good reason. Mateusz Konieczny (talk) 11:27, 4 November 2017 (UTC)

Just because it is a specifized warning banner, and does not indicate a recommanded tagging but an alternate tagging not described really on this page. These warning banners are still at bottom of page, in the last section (about "errors/mistakes") after the normal description. This does not add anything to the documentation of the tag in the page title. Also the term "possible" implyes a warning (this is not warrantied, and some checks are needed if the indicated "possible synonym" tag should be replaced by the tag described on the page). And there's another notice jsut below against performing automated edits to do the replacement.— Verdy_p (talk) 12:23, 4 November 2017 (UTC)
Look also at this related {{Import bot warning}} banner (which may appear even more proeminently at top of pages):
Verdy_p (talk) 12:24, 4 November 2017 (UTC)
I still see no reason to make this particular message box reddish. Making it white would reduce problem of making it too visible Mateusz Konieczny (talk) 12:31, 4 November 2017 (UTC)
But then we would include the banner above that would be equlally visible but that would apply to the same box that displays bad tags, an optional replacement, and the current usage of this bad practice, but that has not been necessarily banned (that's why no automated bots should be allowed on them).
Only automatic deletion is documented but this happens silently in editors for "discardable" tags (that don't need this template at all as they have no replacement as "tags" for OSM objects), which still do not allow mass deletion with prior approval (when most of the time this is not even needed as discardable tags will rapidly disappear on any other edits on objects; if there remains ony discardable tags on ways and they are not used as polygonal borders for relations, these will be deleted automatically, or validtors will immediately detect these relations do not have any useful tags and that there are untagged nodes not used by ways or relations, or untagged ways not used by relations). Those discardable tags are hidden by default in editors.
So what remains is a strong notice about the non-automated removal, which is still coherent here with the warning banner and equally visible (that must not be ignored). — Verdy_p (talk) 15:33, 4 November 2017 (UTC)

Make it mobile-friendly

Viewing the template (e.g. Key:amenity) on a mobile browser (tried Chrome and Lightning on Android with 720x1280 resolution), it's only easy to read if the phone is rotated into landscape, with a big gap on the right. If the phone is rotated into portrait mode (i.e. normal view), most of the text is limited to one character per line, making it a vertical-reading mess with the text outside of the red box. I did a test edit preview, and it looks like changing the "300" on the first line of the template to "100" will fix this, but I don't know what that'll do to rtl languages. Is "300" needed? --goldfndr (talk) 09:45, 14 January 2018 (UTC)

In fact the wiki still has no correct CSS for viewing it on a mobile, even the standard catagories have a giant layout with huge buttons stacked on top of each other and big fonts for each listed category (and these are not even hidden/unrollable by default. The left side bar is also not relocated.
This wiki still does not have the mobile view found in Wikipedia for example: this supprot has still not been integrated here. We have to wait an see what will happen when the mobile view will be added. But this template is less important than others, that will need to be adapted in the central page content for the mobile view. — Verdy_p (talk) 10:38, 14 January 2018 (UTC)
Note: the gap to the right is needed because of the infobox to the right (and because of the fact that the Taginfo uses an iframe which overlaps any infobox to the right. In a prior version, this template had a "clear" but then the possible synonyms would show largely below the infobox, creating a giant vertical blank margin in the article that used any infobox or other blocks flating on the right (including images). Removing the "clear" required adding this right margin to avoid the overlap.
For the mobile, we neeed something else but the infobox must first behave differently: not all tag description pages have this possible synonym templates, but all of them have a righ-floatting infobox. So the first step is to know what to do with the infobox.
A possible solution would be either:
  • to make the PossibleSynonym box also behave like a right-floatting block (just like the infobox), so that it will stack below it. But this would require changing the placement of the PossibleSynonym on the page (for now they are located in a section at bottom of page, they would have to be moved at top of page, not in a section, but after or within the top infobox.
  • use mobile-specific CSS to remove the right margin if the screen width is narrow: this requires "@media {...}" conditional directives in a separate CSS stylesheet, and for now we cannot do that in the template itself which onbly supports inline CSS.
Note: this wiki also still does not supports the recent MediaWiki extension for building (while parsing the wiki page) a custom CSS stylesheets that can be imported separately (and automatically) from the generated HTML for the page, a very useful extension which also avoids mixing content with presentational CSS repeated everywhere (notably for presenting data tables with simple page-specific custom class names, or with simple selectors in the stylesheet, rather than overlong CSS properties for each data item). — Verdy_p (talk) 10:46, 14 January 2018 (UTC)
Thank you for your exhaustive explanation of why "300" must remain, I appreciate it. I'll settle for rotating my phone. --goldfndr (talk) 11:25, 14 January 2018 (UTC)