Template talk:PossibleSynonym
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)
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):
_-_The_Noun_Project.svg){kind=small}
See Import/Guidelines and Automated Edits code of conduct for more information. Imports/automated edits which do not follow these guidelines might be reverted!
- — 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)
- 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)
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)
Similar template available?, just for only key discrepancy.
Thanks for this convenient template. I'm looking for similar one, for only für key (discrepancy), and not the whole tag (k=v), because i just tried to use it for key contact:phone_1 and this seems not working, see here:
Instead of a correct working tag example:
Is there such a requested template available right now?--MalgiK (talk) 22:35, 3 December 2019 (UTC)
- Tried by myself, created {{PossibleSynonymKey}}, for example see:
Feature request: full-text, case-insensitive value search
The taginfo search link returns exactly 112 exact matches for name=fixme, but a full-text search returns almost 1500 keys name containing fixme anywhere in the value. Additionally, most of them (~ 1300) are mixed-case or upper-case variants, but the Overpass link does a case-sensitive (lower-case) search.
In this example, I linked taginfo manually in the parameter observation as a workaround (with = replaced with {{=}} in the URL) but there should be a template parameter to make it straightforward to choose the search type for the value, and perhaps for the key. (edit) In fact, many results in the example above have variants of the key name, like uic_name name:ja_rm boundary_name.
--Pippo6 (talk) 09:39, 24 May 2020 (UTC)
Pointlessness
If these are not an exact synonyms then this templates induce bad edits.
If these are in fact exact synonyms: then proposing mass replacement edit (or ongoing bit edit with bot) would be a better idea than templating the wiki with red banners
Mateusz Konieczny (talk) 18:08, 23 February 2024 (UTC)
- I like this template because it informs people that there are many common tagging mistakes or typos. There are many people who like correcting typos, so it's good to have them on the Wiki. I wouldn't call them synonyms. I always name the section "Possible tagging mistakes". Why induces bad edits? I don't understand. I'm a Wiki editor and when I find common typos of tags, I add this template - other people are OSM mappers who like to correct these tagging typos. maro21 18:23, 23 February 2024 (UTC)
- "Why induces bad edits?" in cases where it as added and it turns out that it is not an actual synonym. Mateusz Konieczny (talk) 07:47, 22 March 2024 (UTC)
- Unfortunately synonyms are a fact of life in OSM. Often people disagree on whether to merge synonyms. For example, we still have waterway=riverbank remnants despite my very public campaign to get concurrence on eradicating it. I think it's unrealistic to think that we can just wave our hands and make the synonyms go away through a quick bot edit. At least a template can alert people to the fact that there's a disgreement on what a thing should be tagged. --ZeLonewolf (talk) 18:52, 23 February 2024 (UTC)
- "Often people disagree on whether to merge synonyms." - and in such case putting large red "please retag me" banner is really unhelpful. Yes, automated edits get a disclaimer - but in practice people treat it as retagging targets, sometimes with dubious review. Mateusz Konieczny (talk) 08:18, 22 March 2024 (UTC)
- Tag:water=river is actually a good example of case where this template is not so helpful. "Possible tagging mistakes" is not really true - what remained is actually apparently preferred by local community, in such case describing the retagging campaign and some remaining holdouts would be better than putting red banner. Mateusz Konieczny (talk) 08:18, 22 March 2024 (UTC)
- "I think it's unrealistic to think that we can just wave our hands and make the synonyms go away through a quick bot edit" waving hands is not sufficient but in general situation is typically either obvious and bot edit is possible or it is not really a match or there is some real opposition to retagging. {{PossibleSynonym}} is not useful in either case and spending time on finding values which could be listed with it seems utter waste of time. This template being the most prominent element of pages does not help Mateusz Konieczny (talk) 08:18, 22 March 2024 (UTC)
Irony
The irony of there being two "Possible Synonym" templates is not lost on me. Perhaps we should compress them into one template? --Geordannik (talk) 08:59, 16 September 2024 (UTC)
- Why? maro21 15:25, 16 September 2024 (UTC)