Template talk:Taginfo

From OpenStreetMap Wiki
Jump to navigation Jump to search


This is just a shortcut for embeding Taginfo info boxes in other pages. Both parameters are mandatory.






See also


--Pyrog (talk) 08:24, 20 September 2013 (UTC)

If we really need such functionality, I would prefer it as own template. --Andi 22:35, 20 September 2013 (UTC)

Missing "area"

Is it possible to add an element "area" to Taginfo? --Władysław Komorek (talk) 13:57, 2 December 2013 (UTC)

Link Parameter

I suggest to add a link parameter. The value yes display only a link to tag info and hide the taginfo box.


(Copied from Talk:Taginfo/Embedding).

Could be some sort of optional label (key=value) included? Sometimes the taginfo box is used alone so there is need for labeling. Template:Taginfo_wrapper ist not very elegant and not well known.

+1 --Pyrog (talk) 07:16, 23 November 2020 (UTC)

If it does not get integrated into the taginfo box perhaps we could include it in the template. I came across when during creation of Talk:Tag:shop=e-cigarette.--Jojo4u (talk) 09:24, 11 August 2015 (UTC)

AJAX rewrite

ZeLonewolf is proposing a rewrite of this template using AJAX calls to the Taginfo API for more control over the presentation and localization of the statistics box. – Minh Nguyễn 💬 06:23, 3 January 2021 (UTC)

An error when parameters are empty


If I type {{Taginfo|}} and press "Preview", there is an internal error and all the entered text is lost! Even if I want to go back to the previous page in my browser. Can this be fixed? There is no such issue with other templates, for example {{Tag||}}: [[Key:|]]=*. maro21 20:41, 27 November 2021 (UTC)

Ouch, you're right. Please open an issue in the MediaWiki extension's issue tracker. In the meantime, consider using {{Taginfo2}} instead: that alternative implementation falls back to a simple link. It's implemented using AJAX, so it won't cause MediaWiki to run into an internal server error in any case. – Minh Nguyễn 💬 21:09, 27 November 2021 (UTC)

Migrate to AJAX-based rewrite

Should we migrate this template from the longstanding MediaWiki extension to the AJAX-based implementation by ZeLonewolf in {{Taginfo2}}? The rewrite has a more compact layout and can be localized (though few localizations have been contributed so far). It has been soft-launched on 70 pages since February. It requires JavaScript but displays a link as fallback for unsupported configurations. The complimentary taglists functionality is already AJAX-based.

The extension requires ongoing low-level maintenance as MediaWiki is periodically upgraded. When there are problems, it has the potential to trigger an internal error and bring down every page that embeds taginfo, including every key and tag description page. [1] The AJAX-based implementation is capable of similar problems, even XSS issues, but MediaWiki's client-side API environment is more stable and better understood.

 – Minh Nguyễn 💬 21:16, 2 January 2022 (UTC)

Go ahead. It’s ready as far as I’m concerned. --Andrew (talk) 19:48, 4 January 2022 (UTC)
Both templates have advantages and disadvantages. The main disadvantage of the "2" version is that it is loading much more longer... The results of {Taginfo} I can see almost immediately, but for {Taginfo2} is around 2 seconds :(.
But how do you want to migrate? To use it in infoboxes?
I would give people possibility to choose and use both of them. We should also give people information and time to translate this template to at least some popular languages on the Wiki. maro21 19:38, 5 January 2022 (UTC)

@Maro21: The proposal is to completely eliminate the current extension-based implementation of the embed by replacing the contents of this template. The status quo is that people can choose between {{Taginfo}} and {{Taginfo2}} when editing a page. However, there's no way to choose between the two templates when viewing the page. (Even if we implemented something like that, you'd get the downsides of both templates in terms of loading time and fragility.)

The delay you're seeing is because MediaWiki delays most JavaScript from running until the page has fully loaded, whereas the extension-based implementation relies on an iframe that can load independently. On most MediaWiki installations, the delay before loading JavaScript is very short, but it's always been extremely long on this wiki. I've never figured out why; maybe we aren't configuring ResourceLoader correctly.

 – Minh Nguyễn 💬 19:09, 9 January 2022 (UTC)

What do we want - a better look and the ability to translate (as in Taginfo2) or fast loading? How about combining these two features in one template? Fast template with the new design. maro21 20:23, 16 January 2022 (UTC)
@Maro21: Unfortunately, we have to choose between a difficult-to-maintain extension that embeds an untranslated webpage and a translatable gadget that can only load later with the rest of the site JavaScript. If time-to-load is a problem, we need to figure out why site JavaScript takes so long to load. – Minh Nguyễn 💬 22:42, 22 January 2022 (UTC)
I'm fine with migration to "2". IMO pros in layout are: Header with tag name, total amount. I wonder if we could change default to "no" with countNodes, countWays, countRelations? In many cases it is sufficient to have total. - I prepared German translation at Template_talk:Taginfo2#in_other_languages. --Chris2map (talk) 09:43, 16 January 2022 (UTC)
@Chris2map: The taginfo box is used in a lot of contexts where I think the per-type breakdown would be meaningful. For example, it often serves as a fact-check for the nodewayarearelation boxes in infoboxes on tag and key description pages. It can be redundant when multiple tags are being compared against each other. Ideally, we'd have a similar template that can display something like this tag comparison table. – Minh Nguyễn 💬 22:42, 22 January 2022 (UTC)
In any case there still can be set the available options to customize output. I think that total existence is in several cases enough for the fast check and details can be found always via link to taginfo. And if one want's detailed output, could use the options. E.g. with a comparison. But I see, there are just as many cases in which the detailed output is good information. So it is ok to me to keep default behaviour as is. Finally it is about when you have to write down optional parameters and when not. - By the way: Thank you for taking and setting up German translation! --Chris2map (talk) 08:22, 23 January 2022 (UTC)
We could slowly implement this template in different places. To start with, I suggest to replace it in {{PossibleSynonym}} template. This is highly used template, more people will see it and can comment and it may motivate translators to translate it into more languages.
I wouldn't replace the code of this template, but replace {Taginfo} with {Taginfo2} in templates - to keep the history and have working alternative to use. maro21 22:20, 19 March 2022 (UTC)