View source for Template talk:Infobox bridge/Archive 2

{{talkarchivenav}}

== Suppress the coords being generated ==

How do you suppress the title coords from being automatically generated? This infobox has been added to articles already with infoboxes with title coords and causing duplicate title coords. Thanks  [[User:Kerry Raymond|Kerry]] ([[User talk:Kerry Raymond|talk]]) 03:09, 14 January 2020 (UTC)
:Always link to examples of the problem you are describing. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 04:16, 14 January 2020 (UTC)
:: one edit back, two infoboxes, second box has no coordinates tag included but the infobox is picking up the data from the historic site infobox and displaying it</br>[https://en.wikipedia.org/enwiki/w/index.php?title=Mount_Spec_Road_and_Little_Crystal_Creek_Bridge&oldid=935687221 edit example] [[User:Dave Rave|Dave Rave]] ([[User talk:Dave Rave|talk]]) 04:37, 14 January 2020 (UTC)
:: the infobox bridge picks up the coord values even though not presented, even when marked embedded, but the historic site does not show the coords when not present after embedding [[User:Dave Rave|Dave Rave]] ([[User talk:Dave Rave|talk]]) 04:44, 14 January 2020 (UTC)
:{{ping|Kerry Raymond}} If you swap the order of the infoboxes, embed the historic in the bridge, mark it ( embed=yes ) and move the coordinates from the second to the first it fixes it [[User:Dave Rave|Dave Rave]] ([[User talk:Dave Rave|talk]]) 04:44, 14 January 2020 (UTC)
: hmmm, the bridge infobox might not best represent the road article, still, it's a workaround, of sorts [[User:Dave Rave|Dave Rave]] ([[User talk:Dave Rave|talk]])

::Indeed, I'm not here looking for a workaround that (as you say) doesn't really work at all well in this article. I don't think any infobox should be auto-emitting coords like this without a way to suppress it. It seems very arrogant to assume that this bridge infobox's coords should override any other coords in the article. And frankly it wastes a lot of people's time figuring out what's going on when infoboxes behave unexpectedly like this. [[User:Kerry Raymond|Kerry]] ([[User talk:Kerry Raymond|talk]]) 04:53, 14 January 2020 (UTC)
:::Perhaps the solution is to emit the coords automatically as "inline" and not as "title". And have a field (say "coords_as_title" which also adds them as the title coords which can be used when appropriate). [[User:Kerry Raymond|Kerry]] ([[User talk:Kerry Raymond|talk]]) 05:20, 14 January 2020 (UTC)
::::This article has the unusual situation of containing two infoboxes. Strange things can happen when you do that. I believe that I have [https://en.wikipedia.org/enwiki/w/index.php?title=Mount_Spec_Road_and_Little_Crystal_Creek_Bridge&type=revision&diff=935701940&oldid=927233679 worked around the issue] in a reasonable way. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 05:49, 14 January 2020 (UTC)

== Updated mapframe code ==

I have updated the mapframe code to match other structure infoboxes.  it should function the same as before, but there may be a few pages showing maps that weren't before since it can now access the {{para|coordinates}}.  let me know if you see any problems! [[User:Frietjes|Frietjes]] ([[User talk:Frietjes|talk]]) 13:45, 16 July 2020 (UTC)
:{{re|Frietjes}} Was the removal of the red area outlines (for the pages with a Wikidata item linked from an OSM object) intentional? [[User:Jc86035|Jc86035]] ([[User talk:Jc86035|talk]]) 17:49, 25 July 2020 (UTC)
::[[User:Jc86035|Jc86035]], this was not intentional.  can you provide a link to a page where this feature was being used?  [[User:Frietjes|Frietjes]] ([[User talk:Frietjes|talk]]) 14:12, 27 July 2020 (UTC)
:::{{re|Frietjes}} It used to work in the infobox documentation, since [https://www.openstreetmap.org/way/205149952 the OpenStreetMap area object] for the [[Sydney Harbour Bridge]] links to the Wikidata item, and the example uses {{para|qid|Q54495}}. ({{para|qid}} wouldn't be necessary on the article about the bridge, and the red outline should display on the article about the bridge as well, since the article now displays the mapframe.) [[User:Jc86035|Jc86035]] ([[User talk:Jc86035|talk]]) 14:27, 27 July 2020 (UTC)
:::: [[User:Jc86035|Jc86035]], do you know how to test if outline is available?  for now, I have added {{para|mapframe-point|none}} but I would like to set this only if there is no available outline map.  so far my attempts to test for it have failed. [[User:Frietjes|Frietjes]] ([[User talk:Frietjes|talk]]) 15:26, 27 July 2020 (UTC)
:::::{{re|Frietjes}} I don't know exactly how it used to work because I didn't write the implementation; I just copied it from {{tl|Infobox building}}. [[User:Jc86035|Jc86035]] ([[User talk:Jc86035|talk]]) 15:28, 27 July 2020 (UTC)
:::::: [[User:Jc86035|Jc86035]], okay, I have rolled back to the old version until I can figure out how to make that work.  otherwise, pages like [[Norfolk Southern–Gregson Street Overpass]] and [[Abraham Lincoln Memorial Bridge]] are failing with an error message. [[User:Frietjes|Frietjes]] ([[User talk:Frietjes|talk]]) 15:31, 27 July 2020 (UTC)

== Fetch from wikidata ==

I am working on a version that can pull certain fields from Wikidata. Progress can be seen in the sandbox. Comments welcome. &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 14:22, 22 September 2020 (UTC)
:Thank you for using WikidataIB so that only sourced data will be retrieved. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 15:34, 22 September 2020 (UTC)
::I was intending to leave that to editorial discretion on each separate article, so {{para|onlysourced}} can be set appropriately. Yes I know how contentious this can be! &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 16:46, 22 September 2020 (UTC)

== Record traffic ==

Is it a good idea to add a "record traffic" parameter?--[[User:Александр Мотин|Александр Мотин]] ([[User talk:Александр Мотин|talk]]) 18:04, 18 August 2020 (UTC)
:I would suggest not, because it can only be true at one particular moment in time. So it will be instantly out of date. &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 08:59, 22 September 2020 (UTC)
:Actually perhaps I misunderstood. There is already a ''traffic'' field for "average daily traffic". I remain unconvinced that this is useful ... Can you explain what you mean by "record traffic"? &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 09:02, 25 September 2020 (UTC)

==Website field not working==
Spiting up duplicates and span. (See [[Crimean Bridge]]) [[User:Smeagol 17|Smeagol 17]] ([[User talk:Smeagol 17|talk]]) 11:11, 28 September 2020 (UTC)

:Data entry error; fixed. <span class="vcard"><span class="fn">[[User:Pigsonthewing|Andy Mabbett]]</span> (<span class="nickname">Pigsonthewing</span>); [[User talk:Pigsonthewing|Talk to Andy]]; [[Special:Contributions/Pigsonthewing|Andy's edits]]</span> 11:24, 28 September 2020 (UTC)
: Thanks.[[User:Smeagol 17|Smeagol 17]] ([[User talk:Smeagol 17|talk]]) 17:05, 28 September 2020 (UTC)

== Demolished ==

We have a field for "destroyed" which probably does not occur very often. But we are missing a field for "demolished" or "dismantled" which is much more likely. Should it be added? &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 08:23, 24 September 2020 (UTC)
:The code for this is now in the sandbox &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 20:30, 27 September 2020 (UTC)
:And {{Added}} &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 08:38, 30 September 2020 (UTC)

== Onlysourced ==

As statements about bridges are unlikely to be too controversial, I am thinking about setting {{para|onlysourced|no}} so that unsourced statements from Wikidata can be used in the infobox. This is equivalent to setting fields on Wikipedia as no sources are required to verify each separate field. What do people think? &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 16:31, 10 October 2020 (UTC)
:{{done}} &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 13:10, 28 October 2020 (UTC)

== Mapframe ==

I propose we add the standard implementation of mapframe (see [[Wikipedia:Mapframe maps in infoboxes]]) and remove the pushpin map functionality entirely &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 13:10, 28 October 2020 (UTC)
:Code is on the sandbox. Test cases can be seen on [[Template:Infobox bridge/testcases]] &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 19:54, 4 December 2020 (UTC)
:Deployed. If this is controversial then let me know and I will revert and then look at introducing it more gradually and without overriding custom maps &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 21:18, 5 December 2020 (UTC)

==Multiple coordinates==
After [[User:MSGJ|MSGJ]]'s most recent edits to this template, more than 750 articles have been thrown into [[:Category:Pages with malformed coordinate tags]]—with corresponding error messages in the articles themselves—because the infoboxes are now including Wikidata coordinates even though the articles already contained coordinates in {{tlc|coord}} templates (sometimes in other infoboxes, often outside an infobox). Presumably many of these articles could be fixed by manually moving each article's existing {{tlc|coord}} template into a {{para|coordinates}} field in the infobox, thus overriding the Wikidata coordinates, but it's a tall order to manually do this to so many articles in a reasonably short time and in some cases it's more appropriate for the coordinates to be in another infobox. Is there some way to code this template so that Wikidata coordinates are not added to Infobox bridge if the article already contains a {{tlc|coord}} template elsewhere? [[User:Deor|Deor]] ([[User talk:Deor|talk]]) 16:40, 24 September 2020 (UTC)
:Will look at this now. It was not my intention to override in the manner you describe. &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 16:43, 24 September 2020 (UTC)
:I have reverted that change and the error messages have disappeared. Sorry about not testing that properly. &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 16:55, 24 September 2020 (UTC)
::{{ping|MSGJ}} I don't know how you got the error messages to disappear, but the articles are still displaying multiple sets of coordinates in the title position, which is a no-no. (See [[Boston Bridge]], for example.) If you insist on importing Wikidata coordinates in this template, perhaps it would be best to change the display parameter from "inline,title" to just "inline". That might produce no title display of coordinates in some articles, but it would eliminate the problem of overlapping displays. [[User:Deor|Deor]] ([[User talk:Deor|talk]]) 17:18, 24 September 2020 (UTC)
:::As far as I know I have reverted this part of the template code to the version before I changed anything. I'll see if I can get some advice on what is going wrong. &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 17:25, 24 September 2020 (UTC)
:::I have asked {{ul|Jonesey95}} to assist here, but they are not online at the moment. I repeat that the code currently handling coordinates in this template is the same code before I arrived, so I assume these errors have been present for a while. I don't know why the error tracking category is not being populated with this - could it be because the ''coordinsert'' function of [[Module:Coordinates]] is being used rather than ''coord''? (But I don't know what the difference is.) &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 13:25, 25 September 2020 (UTC)
::::I put the version of this infobox from 5 October 2019 into the sandbox, and that version also shows two overlapping sets of coordinates in the title position at [[Boston Bridge]]. That appears to indicate that this problem has been with us for a while. 
::::
::::I think there may be a workaround for this problem, which is that a {{tl|coord}} template exists in the article but outside the infobox, so the infobox pulls coordinates from  Wikidata. Pinging {{Ping|Mandruss|Jc86035}} do you know how to detect these duplications? 
::::
::::In the long run, the best fix is probably to find all articles that use {{tl|coord}} outside of the infobox and either move it inside the infobox or remove it and use the Wikidata coordinates. [https://petscan.wmflabs.org/?sitelinks_no=&cb_labels_no_l=1&templates_yes=Infobox%20bridge%0ACoord&categories=Coordinates%20on%20Wikidata&edits%5Bbots%5D=both&edits%5Banons%5D=both&interface_language=en&active_tab=tab_templates_n_links&depth=1&edits%5Bflagged%5D=both&cb_labels_any_l=1&search_max_results=500&language=en&ns%5B0%5D=1&project=wikipedia&cb_labels_yes_l=1&maxlinks=&doit= This search] shows all Infobox bridge articles with coordinates in Wikidata that also use the {{tl|coord}} template (currently 4,500 articles out of 5,360 that use this template), but it doesn't show whether the template is inside the infobox or outside it. You may need a temporary tracking category to determine which pages use {{tl|coord}} outside the infobox; I can probably set that up. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 05:27, 28 September 2020 (UTC)
:::::Responding to ping, but I don't think I can be of much help. I'm Wikidata-ignorant, I know nothing of the internals involved, and I don't get why the problem exists only for Infobox bridge. Is it the only infobox that pulls coords from Wikidata?{{pb}}{{smaller|1=Tangentially, I assume Wikidata is global; ie a single entry for a given entity is used by all wikis, correct? That makes me wonder how Wikidata interacts with a local guideline like [[Wikipedia:WikiProject Geographical coordinates#Precision guidelines]]. Perhaps someone here would care to enlighten me at my UTP.}} &#8213;[[User:Mandruss|<span style="color:#775C57;">'''''Mandruss'''''</span>]]&nbsp;[[User talk:Mandruss|<span style="color:#888;">&#9742;</span>]] 06:10, 28 September 2020 (UTC)
:::::Thanks for helping Jonesey. I think a tracking category is a good idea; I don't mind helping fix some of these. As Deor mentioned above, these would normally be caught by [[:Category:Pages with malformed coordinate tags]] but for some reason it is not - do you know why? The template uses the ''coordinsert'' function of the module - what is the difference between this and ''coord''? &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 10:09, 28 September 2020 (UTC)
::::::I have created {{cl|Pages using infobox bridge with empty coordinates parameter}}, a temporary tracking category that should contain all of these "duplicate coordinates" pages once it is populated. [https://petscan.wmflabs.org/?&edits%5Bbots%5D=both&cb_labels_yes_l=1&edits%5Banons%5D=both&edits%5Bflagged%5D=both&cb_labels_any_l=1&cb_labels_no_l=1&language=en&categories=Pages%20using%20infobox%20bridge%20with%20empty%20coordinates%20parameter&ns%5B0%5D=1&search_max_results=500&templates_yes=coord&depth=1&interface_language=en&active_tab=tab_templates_n_links&project=wikipedia&search_query=&doit= This search] is supposed to show articles that have an empty {{para|coordinates}} parameter and that also contain the {{tl|coord}} template somewhere within the article. If it works, someone can go through that list of articles and move the coord template into the infobox. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 20:08, 28 September 2020 (UTC)
:::::::I'm not sure this  category is really tracking the articles we need to find. Also you didn't answer my question. &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 06:47, 29 September 2020 (UTC)
::::::::I looked at a sample of the pages in the category, and about half had duplicate coordinates. That's pretty good. I don't know the answer to your question; it might be worth asking at VPT or the category talk page or the talk page for Template:Coord. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 13:00, 29 September 2020 (UTC)
:::::::::A category to track a particular error, in which only half the articles contain that error does not seem fantastically useful :)) For now I have put my version of the code back, because at least it triggers [[:Category:Pages with malformed coordinate tags]] so that these can be fixed &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 13:54, 29 September 2020 (UTC)
I have decided that the only way to remove these errors is to temporarily stop this template from retrieving coordinates from wikidata unless explicitly told to. As far as I can tell {{ul|Rehman}} added this feature in 2018 and it has been buggy since then. Unless there is way to detect if there is a call to {{tl|coord}} somewhere else on the article, then there is no way to prevent the duplication of these coordinates. &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 08:32, 30 September 2020 (UTC)
:In that case, I'm pretty sure that the search I linked above will detect articles with coord templates outside of infobox bridge. I think. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 13:21, 30 September 2020 (UTC)
::Okay, understood. I think in the first instance my priority is to find any articles which may have lost their coordinates as a result of the recent change, i.e. articles ''not'' containing {{tl|coord}}, ''not'' defined in the infobox, but defined at Wikidata. If you know a way to track these, please let me know. &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 10:46, 1 October 2020 (UTC)
:::Maybe [https://petscan.wmflabs.org/?negcats=Coordinates%20on%20Wikidata&language=en&edits%5Bflagged%5D=both&search_max_results=500&edits%5Banons%5D=both&cb_labels_no_l=1&categories=Pages%20using%20infobox%20bridge%20with%20empty%20coordinates%20parameter&cb_labels_yes_l=1&cb_labels_any_l=1&interface_language=en&depth=1&ns%5B0%5D=1&project=wikipedia&edits%5Bbots%5D=both&sitelinks_any=&doit= this search]? I admit that I am a little confused at this point as to the state of the template in relation to Wikidata. [[Burnside Bridge]], for example, is in the "no coordinates" category, but it has a "coordinate location" on Wikidata. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 13:38, 1 October 2020 (UTC)
::::Yes! That looks like a useful search and [[Burnside Bridge]] is exactly the kind of article I need to find. The template no longer takes coordinates from wikidata by default, so I need to set {{para|fetchwikidata|coordinates}} &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 16:38, 1 October 2020 (UTC)
:::::And [https://petscan.wmflabs.org/?&edits%5Bbots%5D=both&cb_labels_yes_l=1&edits%5Banons%5D=both&edits%5Bflagged%5D=both&cb_labels_any_l=1&cb_labels_no_l=1&language=en&categories=Pages%20using%20infobox%20bridge%20with%20empty%20coordinates%20parameter&ns%5B0%5D=1&search_max_results=500&templates_yes=coord&depth=1&interface_language=en&active_tab=tab_templates_n_links&project=wikipedia&search_query=&doit= this search] may contain articles using the coord template outside of the infobox; moving the template inside the infobox is probably desirable. Again, I don't know how Wikidata interacts with that list of articles. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 17:00, 1 October 2020 (UTC)
::::I have cleared out all those articles, so they should all be displaying coordinates now &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 21:11, 1 October 2020 (UTC)
:{{ping|MSGJ}} The duplicate title coordinates were caused by a bug in the [[Module:WikidataIB|WikidataIB module]]. It should be fixed now. See discussion at [[Module talk:WikidataIB#Wrong default for display parameter passed to Coord template by getCoords]]. [[User:Kaldari|Kaldari]] ([[User talk:Kaldari|talk]]) 01:16, 9 December 2020 (UTC)
:: Indeed. The getCoords function in WikidataIB always used a default of "inline, title" when no {{para|display}} was set, although that could have been overridden from any infobox design by supplying {{para|display|inline}}. The function actually calls [[Template:Coord]] to render the display, so I've now set the default in the getCoords function to be nothing, which will allow it make use of the default in [[Template:Coord]] for compatibility. Please let me know if any problems persist. --[[User:RexxS|RexxS]] ([[User talk:RexxS|talk]]) 04:54, 9 December 2020 (UTC)
:::{{ping|Kaldari|RexxS}}: thanks for looking at this. The duplicate and clashing display of two coordinates in the top right corner was one of the problems (and the most pressing) but the other was the fact that having two definitions on the same page was triggering an error category [[:Category:Pages with malformed coordinate tags]] which made {{ul|Deor}} unhappy. Is there any way that the coordinates defined from WikidataIB can be supressed if there is already a {{tlc|coord}} template somewhere on the article? (My understanding is that the answer is "no", which means that coordinates cannot be taken from Wikidata by default, but only by setting {{para|fetchwikidata|coordinates}} when an editor or bot has confirmed there is no {{tlc|coord}} template present.) &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 14:17, 9 December 2020 (UTC)
::::{{ping|MSGJ}} A better solution would probably be to remove the extra {{tl|coord}} template (as I think you've already been doing). What is the ideal end result that you want on bridge articles? Let's start with that, and I can help you work backwards to a solution. Do you want bridge articles to have coordinates in the title bar? [[User:Kaldari|Kaldari]] ([[User talk:Kaldari|talk]]) 16:30, 9 December 2020 (UTC)
:::: {{ec}} {{re|MSGJ}} the first thing I'd ask is whether the logic that triggers the error category is correct. Is there any good reason why coordinates should not be displayed both in the article text and in the infobox? Why would we want to prohibit that?
:::: We would presumably get exactly the same problem if {{tl|coords}} were already in an article and someone added a local value to the infobox like this: <code><nowiki>|coordinates = {{coord|40.3128|-79.8283}}}}</nowiki></code> (as the documentation implies), so I don't see this specifically as a Wikidata issue.
:::: It is perfectly possible to write a bit of code that tests whether {{tl|coord}} is on the page by getting the page contents and doing a string search. However, that is resource-heavy because it has to load the entire page every time the infobox is rendered. I can write the code to do the test for you if you would like? --[[User:RexxS|RexxS]] ([[User talk:RexxS|talk]]) 16:33, 9 December 2020 (UTC)
::::* <code><nowiki>{{#invoke:String2 |findpagetext |text=Youghiogheny}}</nowiki></code> → {{#invoke:String2 |findpagetext |text=Youghiogheny}}
::::* <code><nowiki>{{#invoke:String2 |findpagetext |text=Youghiogheny |nomatch=not found}}</nowiki></code> → {{#invoke:String2 |findpagetext |text=Youghiogheny |nomatch=not found}}
::::* <code><nowiki>{{#invoke:String2 |findpagetext |text=Youghiogheny |title=Boston Bridge |nomatch=not found}}</nowiki></code> → {{#invoke:String2 |findpagetext |text=Youghiogheny |title=Boston Bridge |nomatch=not found}}
::::* <code><nowiki>{{#invoke:String2 |findpagetext |text=river |title=Boston Bridge |nomatch=not found}}</nowiki></code> → {{#invoke:String2 |findpagetext |text=river |title=Boston Bridge |nomatch=not found}}
::::* <code><nowiki>{{#invoke:String2 |findpagetext |text=[Rr]iver |title=Boston Bridge |plain=false |nomatch=not found}}</nowiki></code> → {{#invoke:String2 |findpagetext |text=[Rr]iver |title=Boston Bridge |plain=false |nomatch=not found}}
::::* <code><nowiki>{{#invoke:String2 |findpagetext |text=%[%[ |title=Boston Bridge |plain=f |nomatch=not found}}</nowiki></code> → {{#invoke:String2 |findpagetext |text=%[%[ |title=Boston Bridge |plain=f |nomatch=not found}}
::::* <code><nowiki>{{#invoke:String2 |findpagetext |text=%{%{[Cc]oord |title=Boston Bridge |plain=f |nomatch=not found}}</nowiki></code> → {{#invoke:String2 |findpagetext |text=%{%{coord |title=Boston Bridge |plain=f |nomatch=not found}}
:::: The search is case-sensitive, so you need to use Lua pattern matching to find <code>river</code> or <code>River</code>. The last one finds <code><nowiki>{{coord</nowiki></code> and <code><nowiki>{{Coord</nowiki></code>. --[[User:RexxS|RexxS]] ([[User talk:RexxS|talk]]) 18:41, 9 December 2020 (UTC)
:::::Hey ... 
:::::*{{green|What is the ideal end result that you want on bridge articles?}} My personal ideal end result would probably be all having all coordinates on Wikidata and none kept locally, but I'm not sure there would be consensus for mass action like that. Please tell me if there is! So my priority is (a) making sure that no article is missing coordinates if they are available on Wikidata while (b) avoiding populating the error category if possible.
:::::*{{green|Do you want bridge articles to have coordinates in the title bar?}} I don't have a strong preference either way, but feel that having it in the infobox ''and'' the title bar is probably overkill. Happy to follow precedent and/or MoS.
:::::*{{green|I don't see this specifically as a Wikidata issue.}} Correct, but the issue is that currently I can't import coordinates from Wikidata if the coordinates are already locally defined.
:::::*{{green|Is the logic that triggers the error category is correct?}} I assume it is not ideal to have two separate coordinate definitions because if they are the same then one is redundant, and if they are different then there is a possible contradiction. Are you suggesting we could leave {{tl|coord}} to create the titlebar and the infobox template to deal with the infobox?
:::::&mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 22:13, 9 December 2020 (UTC)
:::::: It is normal for infoboxes to contain redundant information{{snd}} a requirement, in fact. So I don't see that having the coordinates twice should be more of a problem than having any other piece of information twice - once in the article body and once in the infobox. If we have a date-of-birth in the infobox different from one in the article body, we use that to check which one is accurate and correct the wrong value (which might or might not have come from Wikidata). I don't think that the ability to identify conflicting values of coordinates is a bad thing, as it might turn out that the Wikidata value is more accurate than the one in the article body.
:::::: I've no opinion on how we might prefer to handle it, but I am suggesting that you can code the infobox to only display the coordinates in the infobox if there is no {{tl|coord}} in the article source text by writing something like this:
::::::* <code><nowiki>|  data1      = {{#if:{{findpagetext |text=%{%{[Cc]oord |plain=false}} ||{{#invoke:WikidataIB|getCoords|name=coordinates|fetchwikidata={{{fetchwikidata|}}}|display={{{display|}}}|{{{coordinates|}}}}} }}</nowiki></code>
:::::: That would suppress any coordinate display in the infobox if there was a {{tl|coord}} in the article text. If there was no {{tl|coord}} in the article text, it would allow setting a {{para|display|inline, title}} in an article infobox to put the coordinates in the title as well. Leaving out any display parameter from the infobox would result in the coordinates being shown only in the infobox.
:::::: That's just one possible solution, but the tools are available to create others, depending on what you want. --[[User:RexxS|RexxS]] ([[User talk:RexxS|talk]]) 22:50, 9 December 2020 (UTC)
{{ping|Deor}} do you think it would be okay if the {{tl|coord}} template produced the titlebar link and also the infobox template gets the coordinates from wikidata (or locally if parameter is supplied to template) and displays this in the infobox? There would not be the previous problem of two clashing coordinates in the titlebar. Would this trigger the error category, and if so, would that be a problem? Thanks &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 11:25, 11 December 2020 (UTC)
:Have just tested on [[Boston Bridge]] with the [[Template:Infobox bridge/sandbox]] and the error category is ''not'' triggered, so it seems this should be fine! To be clear, the proposal is that every infobox will display coordinates if they are defined on Wikidata. &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 11:41, 11 December 2020 (UTC)
::If the coordinates in the infobox are set for inline display and the ones in the {{tl|coord}} template are set for title display, the article should not be thrown into the maintenance category. The problem with that solution is cases (which I've run across a number of times) in which the infobox and the title display show ''different'' coordinates—clearly not a desirable state of affairs. (And in instances in which locally added coordinates conflict with coordinates drawn from Wikidata, the problem is often with the Wikidata coodinates, not the local ones.) [[User:Deor|Deor]] ([[User talk:Deor|talk]]) 17:06, 11 December 2020 (UTC)
::: Surely it is desirable to be aware of when the coordinates differ between two different instances in the article or between Wikipedia and Wikidata? Obviously one or the other needs to be corrected/improved, and this is also an indication that sourcing needs to be provided. --[[User:RexxS|RexxS]] ([[User talk:RexxS|talk]]) 17:16, 11 December 2020 (UTC)
:::On [[Boston Bridge]] bridge now I can't even tell whether they are the same or different. One set is 40.3128°N 79.8283°W and the other is 40°18′46″N 79°49′42″W &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 21:54, 11 December 2020 (UTC)
:::: In [[Template:Infobox bridge/sandbox]] I've added a parameter {{para|coord_format}}, which makes use of the getCoords function's ability to set decimal or dms formats for the coordinates. Anything that begins with "dec" sets decimal; anything else, including omission, sets dms. (Yes, I know it needs documenting.) I used it in [[Boston Bridge]] as a demo and you can now see that the coordinates are identical.
:::: If you decide to use it in the production template, you'll have to add it to the list of recognised parameters near the end of the template. Cheers --[[User:RexxS|RexxS]] ([[User talk:RexxS|talk]]) 23:18, 11 December 2020 (UTC)

== Error with website parameter ==

The website parameter in the template seems to be not functioning correctly, when <nowiki>{{url|https://www.example.com}}</nowiki> is added it produces: {{url|https://www.example.com}} <nowiki>www.example.com www<wbr/>.example<wbr/>.com]</span>]</nowiki>

You can see this in an example I made on my [[Special:PermanentLink/985941892|sandbox]] and in the page [[Swing Bridge, River Tyne]] where I first came across this. --[[User:Voello|<span style="font-family:Palatino;color: fireBrick">'''''Voello'''''</span>]] [[User talk:Voello|<span style="color: darkOliveGreen"><sub>''talk''</sub></span>]] 21:50, 28 October 2020 (UTC)
:Yes I can see what you mean. It seems that this parameter is expecting a bare URL whereas Swing Bridge was using {{tl|url}} to format it already. I will have to check whether this is a common problem and, if so, the best way to fix it. &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 22:46, 28 October 2020 (UTC)
::This is related to [[Module_talk:WikidataIB#span_tag_errors_possibly_caused_by_recent_changes_to_URL_handling|changes to Module:WikidataIB]]. I have posted there. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 22:48, 28 October 2020 (UTC)
:::Oh, thanks that's great. Though, if the template is expecting a bare URL not one enclosed with {{tl|url}} the documentation should be updated (if it's not fixed) as for {{para|website}} it currently states "URL to the bridge's website; enclose within {{tl|URL}}". --[[User:Voello|<span style="font-family:Palatino;color: fireBrick">'''''Voello'''''</span>]] [[User talk:Voello|<span style="color: darkOliveGreen"><sub>''talk''</sub></span>]] 11:46, 29 October 2020 (UTC)
::::The documentation has recommended the use of {{tl|URL}} for at least [https://en.wikipedia.org/enwiki/w/index.php?title=Template:Infobox_bridge/doc&oldid=547422139 seven years], so this is not a problem with the documentation. It's a problem with the WikidataIB module that processes the URL; that module was recently modified. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 14:50, 29 October 2020 (UTC)
:I have temporarily stopped using [[Module:WikidataIB]] to get the website on this template. This may mean that some websites are not displayed anymore, but that is better than displaying this mess &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 15:17, 29 October 2020 (UTC)
A new solution using [[Template:URL2]], which was suggested at [[Module talk:WikidataIB#span tag errors possibly caused by recent changes to URL handling]], is now on the sandbox and seems to be working well &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 19:55, 4 December 2020 (UTC)
:Hopefully this is now fixed &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 21:18, 5 December 2020 (UTC)
:Another problem with this field has surfaced. I have temporarily reverted and reported to [[Module talk:WikidataIB]]. Strange that this parameter is causing so many problems! &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 06:49, 3 January 2021 (UTC)
:: It should be fixed now. Part of the problem is that editors can supply urls in alarmingly diverse ways and it's difficult to anticipate all of the possibilities. When you add in the complexity of optionally fetching the information from Wikidata, it becomes a problem that needs a lot of testing to throw up edge cases so that they can be fixed. Unfortunately, this infobox is the first one in such widespread use that has attempted to incorporate this kind of Wikidata extensively, and it's taking the brunt of being the "Phase IV" trials for the techniques. Thanks for your forbearance while I iron out the kinks in the various codes involved. Cheers --[[User:RexxS|RexxS]] ([[User talk:RexxS|talk]]) 14:49, 3 January 2021 (UTC)
:::Didn't realise this template was so cutting edge! &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 20:50, 3 January 2021 (UTC)

== Core parameters ==

I would like to propose a set of basic/core parameters that I feel every bridge article should contain, and which would always display by default if the data is available (i.e. if it is on Wikidata but not yet defined in the article). The following fields are suggested:
* image + caption
* coordinates
* crosses
* official name
* length
* opened
Any opinions on these or other parameters for inclusion? &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 06:55, 3 January 2021 (UTC)
:I think the above "i.e." should read "if it is sourced on Wikidata but not defined in the article". – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 15:18, 3 January 2021 (UTC)
::That's certainly a direction that we could take, and it is one that many editors might agree with. Let me just ask though - are there any fields which you consider to be sufficiently uncontroversial to accept without a reference? I note that we already import coordinates which are not backed up by a reference. &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 17:49, 5 January 2021 (UTC)
:::Perhaps I should be a bit more nuanced in stating my preference. First, I will refer you to [[Wikipedia:Wikidata/2018_Infobox_RfC#Discussion|the latest (to my knowledge) Wikidata/infobox RFC]] closure, which discusses the issue at length. I guess coordinate importing is water under the bridge (sorry), and I can't see forcing referencing on images and captions. Crosses, I don't know; seems pretty self-evident. Official name, length, and opened seem like they should be sourced, though. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 19:56, 5 January 2021 (UTC)
::::Yes I was aware of that RfC, and rereading it again, I find myself still none the wiser! The logical conclusion of your suggestion seems to be to maintain two lists of fields: a "whitelist" to include image/caption, coordinates, crosses and will be displayed regardless of sourcing, and a "greylist?" to include the other fields above which will only be displayed if a suitable reference is included. Other fields (not on either list) will only be displayed if the article explicitly opts in with, e.g. {{para|fetchwikidata|ALL}}. &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 22:14, 8 January 2021 (UTC)
::::: You can set the sourcing on a per-field basis by adding <code><nowiki>|osd=y</nowiki></code> or <code><nowiki>|osd=n</nowiki></code> to the WikidataIB call in the infobox definition, depending on whether you want to return only-sourced values for that field or not. You can also use a parameter to override those choices on a per-article basis by using something like <code><nowiki>|osd={{{onlysourced|y}}}</nowiki></code> and <code><nowiki>|osd={{{onlysourced|n}}}</nowiki></code> instead. --[[User:RexxS|RexxS]] ([[User talk:RexxS|talk]]) 01:54, 9 January 2021 (UTC)
::::::Would the following be advisable and, if so, what would the cleanest way to write the code? If an editor sets {{para|fetchwikidata|length}} on an article then it is reasonable to suppose they have checked the validity of the value, so the value can be displayed without additional checks on the sourcing. But if {{para|fetchwikidata}} does not include length, then it would only be fetched if it was sourced. &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 20:32, 9 January 2021 (UTC)

== Inception ==

Currently we are mapping {{Q|P571}} to "Opened". I am wondering whether it would map more accurately to "Construction start" which is currently defined using the {{{begin}}} parameter. &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 06:48, 3 January 2021 (UTC)
:What is the "inception" of a bridge? When does the bridge start existing? Is it when the construction work starts, or is it when fully complete and opened? &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 17:51, 5 January 2021 (UTC)
:: You can peruse [[d:Property talk:P571]] for a broad variety of opinions about what the property is supposed to mean. Possibly the section [[d:Property talk:P571 #How to proceed when there is more than one creation date?]] might be of interest to those interested in bridges. --[[User:RexxS|RexxS]] ([[User talk:RexxS|talk]]) 21:58, 5 January 2021 (UTC)
:::I posted at [[d:Wikidata:Project chat]] but didn't get much advice. I think I will stick with {{Q|P571}} for "opened" and {{Q|P1619}} for "inaugurated". For construction dates, the best I have seen is:
{{statement+|P={{P-|793}}|V={{Q-|Q385378}}|q1.p={{P-|P580}}|q1.v1=5 January 1933|q2.p={{P-|P582}}|q2.v1=19 April 1937}}
:::That comes from {{Q|Q44440}} &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 22:08, 8 January 2021 (UTC)
:::: That's okay to retrieve:
:::: <code><nowiki>{{wdib|ps=1|qid=Q44440|P793|qual=DATES|qdf=mdy}}</nowiki></code> → {{wdib|ps=1|qid=Q44440|P793|qual=DATES|qdf=mdy}}
:::: <code><nowiki>{{wdib|ps=1|qid=Q44440|P793|qual=DATES|qdf=mdy|qo=y}}</nowiki></code> → {{wdib|ps=1|qid=Q44440|P793|qual=DATES|qdf=mdy|qo=y}}
:::: The latter returns qualifiers only ({{para|qo|yes}} if you just want the values. We use {{q|P793}} a lot for telescopes and observatories because it avoids having to create a new property for each possible event. --[[User:RexxS|RexxS]] ([[User talk:RexxS|talk]]) 01:46, 9 January 2021 (UTC)
:::::Thanks.
:::::#Why does the date default to year only (the documentation says the default is dmy)?
:::::#:<code><nowiki>{{wdib|ps=1|P793|qual=P580|qid=Q44440|qo=y}}</nowiki></code> → {{wdib|ps=1|P793|qual=P580|qid=Q44440|qo=y}}
:::::#And how to remove that dash at the end? (The start date and end date are kept in separate field.) &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 20:52, 9 January 2021 (UTC)
:::::: The date defaults to year only for qualifiers because there were complaints that the output from things like {{q|P1376}} for {{q|Q71}} with full dates was too much for an infobox field:
:::::: <code><nowiki>{{wdib |P1376 |fwd=ALL |osd=no |qid=Q71 |qual=DATES}}</nowiki></code> → {{wdib |P1376 |fwd=ALL |osd=no |qid=Q71 |qual=DATES}}
:::::: Qualifiers usually only want the year, but setting {{para|qdf}} allows the output to be customised.
:::::: Because dates in qualifiers are usually "from this date" /  "to that date" the dash was useful, as in cases like {{q|P610}} for {{q|Q142}}:
:::::: <code><nowiki>{{wdib |P610 |fwd=ALL |osd=no |qid=Q142 |qual=P2044, P1326, DATES}}</nowiki></code> → {{wdib |P610 |fwd=ALL |osd=no |qid=Q142 |qual=P2044, P1326, DATES}}
:::::: I can see that when the qualifier is being used as a pseudo-property, then the dash should not be there, so I've removed it when {{para|qualifiersonly}} is set and there is only only one date to return. I can see that you've already figured out to use {{para|qdf}} for those cases. I apologise that I don't keep the documentation up to date. I'll try to do better. --[[User:RexxS|RexxS]] ([[User talk:RexxS|talk]]) 23:12, 9 January 2021 (UTC)
:::::::Don't apologise! That's very helpful &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 11:46, 10 January 2021 (UTC)

== Parameter request - Channel width ==

Apologies if this is the wrong place to post this; Would it be possible to get a new parameter added to describe the navigability of a maritime channel below the bridge?

For example... |channel-width= ###

[[User:Headphase|Headphase]] ([[User talk:Headphase|talk]]) 10:48, 4 June 2021 (UTC)

== Default parameters ==

I see from above that there apparently are some parameters automatically filled from WD if not specified in the transclusion (although this doesn't appear to be documented). This may be valid for stand-alone infoboxes, but I have an embedded bridge infobox displaying coordinates that are redundant with the parent infobox. Need a way to override this. Embedded infoboxes should only contain unique information with respect to the parent infobox. See [[Harpersfield Covered Bridge]]. [[User:MB|<b style="color:#034503">MB</b>]] 06:53, 26 July 2022 (UTC)

:You're right, this does need documenting. I have fixed the article you mentioned above. We could perhaps change the default behaviour when {{para|embed|yes}} is used? &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 10:21, 26 July 2022 (UTC)
::Setting fetch wikidata to off as you did in this article is probably sufficient, I was unaware that was an option. Changing the default behavior when embedded will work too. [[User:MB|<b style="color:#034503">MB</b>]] 14:18, 26 July 2022 (UTC)

== Image and map widths ==

{{re|MSGJ}} I am attempting to simply make graphics (images and maps) as wide as the infobox by default. There's no reason to have unnecessary whitespace by a narrow image, or a too-wide image jutting out. And if someone had a reason, they can easily change from the defaults. This is a norm in most other highly-used infoboxes. What problem do you have with it? [[User:Ɱ|<span style="text-shadow:#bbb 0.1em 0.1em 0.1em;" class="texhtml">'''ɱ'''</span>]] [[User talk:Ɱ|(talk)]] 21:22, 12 July 2022 (UTC)
:I continue to object to this default image sizing in infoboxes, per [[MOS:IMGSIZE]] ({{tq|Except with very good reason, a fixed width in pixels (e.g. 17px) should not be specified}}). When I look at [[Template:Infobox bridge/testcases]], the Sydney Harbor Bridge image is a reasonable size for me in the live template (no default size, so it uses my preferred thumb size), and the sandbox version ({{U|Ɱ}}'s preferred version) is too small. I have not bothered to revert changes that Ɱ has made to other infoboxes, because I don't care to start edit wars over something that is not actually broken, but I do object to the default pixel sizing and think that MOS should govern. If the image size is too small for the default reader, get the default MediaWiki thumb size increased, or do something else systematic that is not contrary to MOS. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 22:35, 12 July 2022 (UTC)
::This objection is full of bad logic. For starters, you cite [[MOS:IMGSIZE]], which actually '''supports''' what I am doing: {{green|"Cases where fixed sizes may be used include for standardization of size via templates (such as within infobox templates or the display of country flag icons)"}}. As a secondary item, you need to consider the infobox's display to the public. When viewed on desktop and mobile views, to me, to logged-out users, (and I suspect to you especially), the sandbox version displays with the least amount of unnecessary whitespace, and with images and maps lining up by default, unlike in the current version. May I reiterate that this is not just some random wild task I am embracing - it has been discussed multiple times in infobox discussions, and this is a clear preference among users. [[User:Ɱ|<span style="text-shadow:#bbb 0.1em 0.1em 0.1em;" class="texhtml">'''ɱ'''</span>]] [[User talk:Ɱ|(talk)]] 23:27, 12 July 2022 (UTC)
:::Please link to one of those many discussions. The section quoted from [[MOS:IMGSIZE]] links to [[WP:INFOBOXIMAGE]], which recommends using [[Module:InfoboxImage]], which in its documentation says the image size defaults to <code>frameless</code>. If the module is not used,  [[WP:INFOBOXIMAGE]] recommends using <code>frameless</code>, which respects thumbnail preferences.  That seems like multiple consensus recommendations to avoid a default size specification in pixels. The documentation at the module, which was specifically created for use in infoboxes, says {{tq|When "size", "sizedefault", and "maxsize" are not defined, "frameless" is added, which displays the image at the default thumbnail size (220px, but logged in users can change this at Special:Preferences) and is required if using "upright" to scale the default size.}} If somehow 250px is a better default size for infobox images, perhaps that module's default settings should be modified to scale the default size. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 01:00, 13 July 2022 (UTC)
::::Again, incredibly frayed logic. I am directly quoting to you what MOS:IMGSIZE, the ''primary guide to sizing images'', says about how to size infobox images. This is ultra-clear guidance, while neither of the other sources you provided give any actual guidance on the issue whatsoever. This is plain wikilawyering, to wildly come up with an opposite solution to what our Manual of Style clearly states. It allows us to change infobox default sizing; many infoboxes have done so for years and years; and we are be able to here too. I can look into modifying the module as well, thank you for looking into it. [[User:Ɱ|<span style="text-shadow:#bbb 0.1em 0.1em 0.1em;" class="texhtml">'''ɱ'''</span>]] [[User talk:Ɱ|(talk)]] 02:28, 13 July 2022 (UTC)
:::::[[WP:INFOBOXIMAGE]] is a guideline specifically for infoboxes and is part of the MOS. It appears that, as sometimes happens, pieces of the MOS, which is a sprawling set of pages, are not properly aligned. I find nothing wild about the logical sequence of conclusions I reached above, but I can see that, by looking at only one sentence on one MOS page, a person could arrive at a different conclusion. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 05:58, 13 July 2022 (UTC)
::::::[[WP:INFOBOXIMAGE]] does not provide guidance on how we should size images. [[MOS:IMGSIZE]] clearly does. For you to ignore one and read into the other to make an argument contrary to what is plainly stated is not sincere. [[User:Ɱ|<span style="text-shadow:#bbb 0.1em 0.1em 0.1em;" class="texhtml">'''ɱ'''</span>]] [[User talk:Ɱ|(talk)]] 16:05, 13 July 2022 (UTC)
:::::::[[WP:NPA|I am not ignoring anything, and I am engaging sincerely]]. [[WP:INFOBOXIMAGE]] clearly says to use [[Module:InfoboxImage]], which defaults to <code>frameless</code>, which has a default size, so there is definitely sizing guidance there. Regardless, let's try to work together on a fix to the module rather than quibbling over MOS, the latter of which I have never found to be productive. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 17:09, 13 July 2022 (UTC)

Thank you for starting this discussion, it is clearly a contentious issue. I am not dead set against the change but I think changes to widely used templates should be discussed, especially protected ones. Looking at the examples on the testcases I agree that on my browser the wider image does look slightly better. But, like Jonesey, I inherently dislike fixing sizes of images. I would like to know how the numbers 250px and 325px were arrived at. I must admit that I don't understand what  ''frameless'' does, but why in your opinion, is it not ideal in these situations? If all you are trying to achieve is to fill the width of the infobox, then I suspect there is a better way to achieve this. In which case I may support a change to the default parameters of [[Module:InfoboxImage]]. Setting this at the level of individual templates seems like the wrong approach to me &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 11:47, 13 July 2022 (UTC)
:It is not a contentious issue except to one person so far, who chooses to set their images to a large size, which already makes for a poorly-formatted infobox. That is their right - what is not their right is to make a great many infoboxes by-default poorly formatted for every member of the public. I am willing to discuss more. 250px makes the image as wide as the infobox by default, while 325px is a norm for max image size in the infobox. MOS:IMGSIZE specifies even more conservatively - 300px as a max size for the lead image. [[User:Ɱ|<span style="text-shadow:#bbb 0.1em 0.1em 0.1em;" class="texhtml">'''ɱ'''</span>]] [[User talk:Ɱ|(talk)]] 16:09, 13 July 2022 (UTC)

:<code>frameless</code> displays the image without a border or a caption, at the default thumbnail size, which is 220px, or at the editor's chosen thumbnail size, which can be set in the editor's preferences. So for logged-out readers, the Sydney Harbor image shown is 220px, which leaves some white space in the infobox. For me, that same image is 300px, since that is my preference, and 250px is smaller. I believe that the default width of an infobox is 22em, which I could be wrong about, but which is probably relevant, whatever the default width equates to in pixels. I think that a discussion at [[Module talk:InfoboxImage]] with a notice at [[Wikipedia talk:Manual of Style/Infoboxes]] might be helpful. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 14:22, 13 July 2022 (UTC)
::250px is the default width of the infobox, and MOS:IMGSIZE says that for standardization of infobox sizes, image sizes can be fixed, as opposed to scalable, within the infobox. I would be happy to discuss at those pages if you insist - you are the only person with an objection to it so far. [[User:Ɱ|<span style="text-shadow:#bbb 0.1em 0.1em 0.1em;" class="texhtml">'''ɱ'''</span>]] [[User talk:Ɱ|(talk)]] 16:14, 13 July 2022 (UTC)

::{{re|Jonesey95}} is the ideal solution to modify "frameless" to 250px, as opposed to 220px? Allowing you to scale your infoboxes? Scaling images in infoboxes is clearly not preferred in the MOS, but if you won't allow me to modify infobox image sizes any other way (even though I have the guidelines on my side), I can look into it. The only problem is that many frameless images not used in infoboxes will be changed. Truly the best solution is to follow the MOS and simply change Module:InfoboxImage and/or Template:Infobox bridge. [[User:Ɱ|<span style="text-shadow:#bbb 0.1em 0.1em 0.1em;" class="texhtml">'''ɱ'''</span>]] [[User talk:Ɱ|(talk)]] 16:21, 13 July 2022 (UTC)
:::I think the ideal solution would be for [[Module:InfoboxImage]] to assign a default size that is compatible with the default width of infoboxes but that respects editors' thumb size preferences. I ''think'' that might be doable with something like a default of <code>upright=1.14</code> (1.14=250px/220px), but it would require testing. The idea would be to make it so that the infobox image default of <code>frameless</code> applies a size of 250px, but applies a 1.14 scaling factor to whatever thumb size editors have chosen for themselves. Making this change would not affect frameless or thumb images outside of infoboxes, or infobox images that do not use [[Module:InfoboxImage]]. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 17:09, 13 July 2022 (UTC)
::::Okay, this sounds like a valid solution, if possible. I'm not familiar with Lua, do you know how this can be implemented? [[User:Ɱ|<span style="text-shadow:#bbb 0.1em 0.1em 0.1em;" class="texhtml">'''ɱ'''</span>]] [[User talk:Ɱ|(talk)]] 17:14, 13 July 2022 (UTC)
::::{{re|Jonesey95}} Do you have an update on this, or do you know anyone who can assist with it? [[User:Ɱ|<span style="text-shadow:#bbb 0.1em 0.1em 0.1em;" class="texhtml">'''ɱ'''</span>]] [[User talk:Ɱ|(talk)]] 17:57, 5 August 2022 (UTC)

== map_* parameters ==

There are a *lot* (> 1,000, I think) of pages with map_image and other map_ related parameters which I see were deleted. For which of these can the parameter and its data simply be deleted, and are there any where the parameter should change?[[User:Naraht|Naraht]] ([[User talk:Naraht|talk]]) 17:16, 8 September 2022 (UTC)
:It appears that all {{para|map_*}} parameters were [https://en.wikipedia.org/enwiki/w/index.php?title=Template%3AInfobox_bridge&type=revision&diff=992542054&oldid=986058432 removed in December 2020], so there should be no harm in removing those parameters from articles. If the article is not showing a map, adding {{para|coordinates}} may be needed. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 20:33, 8 September 2022 (UTC)
::I'm going to clean them out using AWB. I'll start with a subset of 100 or so.[[User:Naraht|Naraht]] ([[User talk:Naraht|talk]]) 23:56, 8 September 2022 (UTC)

== Demolished should be added to the acceptable. ==

Demolished is a valid parameter, but it still causes the page to go to [[:Category:Pages using infobox bridge with unknown parameters]] [[User:Naraht|Naraht]] ([[User talk:Naraht|talk]]) 17:16, 9 September 2022 (UTC)
:Should be fixed now. [[User:Ɱ|<span style="text-shadow:#bbb 0.1em 0.1em 0.1em;" class="texhtml">'''ɱ'''</span>]] [[User talk:Ɱ|(talk)]] 17:17, 9 September 2022 (UTC)

== Overall unknown parameters. ==

I went through and cleaned out using  what I could from the map_ parameters and a few manual entries. What is left appears to be the following
*map_caption entries, some of which are *very* complicated inclusion having other templates in the value, so trying to write a regex to clean it is difficult.
*mapframe_* entries, it appears these *should* be kept, the rejection list just has to match this.
*pushpin_* entries, are these deleted or are they like map_frame? 
[[User:Naraht|Naraht]] ([[User talk:Naraht|talk]]) 17:46, 9 September 2022 (UTC)
:{{para|pushpin*}} are related to the old map parameters and can be removed. All of the {{para|mapframe-*}} parameters use hyphens, not underscores, AFAICT. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 18:18, 9 September 2022 (UTC)
::Getting rid of the pushpin ones as well.[[User:Naraht|Naraht]] ([[User talk:Naraht|talk]]) 18:47, 9 September 2022 (UTC)

==mapframe_* parameters==
Are these valid or not, I don't see them in the main part of the template?[[User:Naraht|Naraht]] ([[User talk:Naraht|talk]]) 17:13, 9 September 2022 (UTC)
:Yes, they are part of header85, as part of #invoke:Infobox mapframe. [[User:Ɱ|<span style="text-shadow:#bbb 0.1em 0.1em 0.1em;" class="texhtml">'''ɱ'''</span>]] [[User talk:Ɱ|(talk)]] 17:16, 9 September 2022 (UTC)
::It appears that it still makes them go to [[:Category:Pages using infobox bridge with unknown parameters]]. For example, [[Sarah Mildred Long Bridge]] has mapframe_zoom = 13 as one of the parameters. It shows up as an error in the preview and is in the unknown parameters cat.[[User:Naraht|Naraht]] ([[User talk:Naraht|talk]]) 17:34, 9 September 2022 (UTC)
:::The correct parameter was {{para|mapframe-zoom}} (note the hyphen). – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 18:15, 9 September 2022 (UTC)
::::I'll set to a regex to change parameters that are mapframe_ to mapframe- and rerun. Not sure that will get rid of a *huge amount*, but a start.[[User:Naraht|Naraht]] ([[User talk:Naraht|talk]]) 18:46, 9 September 2022 (UTC)
:::::Good call. Please check {{cl|Pages using duplicate arguments in template calls}} when you are done, in case there was already a mapframe-* parameter present. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 19:01, 9 September 2022 (UTC)

==Complete==
At this moment  [[:Category:Pages using infobox bridge with unknown parameters]] is empty[[User:Naraht|Naraht]] ([[User talk:Naraht|talk]]) 04:04, 11 September 2022 (UTC)
:Nicely done. Thanks for this gnoming. – [[User:Jonesey95|Jonesey95]] ([[User talk:Jonesey95|talk]]) 16:17, 11 September 2022 (UTC)

== refs= ==

No documentation in the article about the usage of refs=, so assuming a standard ref and cite template would work in the field. The template validates but doesnt show the reference. Referring to [[w:Frank J. Wood Bridge|Frank J. Wood Bridge]] [[User:Jake-jakubowski|Jake-jakubowski]] ([[User talk:Jake-jakubowski|talk]]) 19:38, 22 September 2022 (UTC)

:I may be wrong, but I think giving references for data in infoboxes is largely deprecated these days. It is better to provide the reference for the fact in the body of the article. &mdash;&nbsp;Martin <small>([[User:MSGJ|MSGJ]]&nbsp;·&nbsp;[[User talk:MSGJ|talk]])</small> 19:46, 22 September 2022 (UTC)
::Gotcha, thank you! [[User:Jake-jakubowski|Jake-jakubowski]] ([[User talk:Jake-jakubowski|talk]]) 19:54, 22 September 2022 (UTC)

== Template-protected edit request on 18 February 2023 ==

{{edit template-protected|Template:Infobox bridge|answered=yes}}
Change | label59    = [[Railway electrification system|Electrified]] to link to [[Railway electrification]] --- <span style="font-family: 'Verdana';"><span style="color:red"><span style="font-size:120%">'''Tbf69'''</span></span></span> [[User:Tbf69|P]]&nbsp;&bull;&#32;[[User talk:Tbf69|T]] 10:24, 18 February 2023 (UTC)
:{{not done|Not edited}} in accord with [[WP:NOTBROKEN]] editing guideline. Thank you very much for your contributions''!'' '''''[[User:Paine Ellsworth|<span style="font-size:92%;color:darkblue;font-family:Segoe Script">P.I.&nbsp;Ellsworth</span>]]'''''&thinsp;,&nbsp;[[Editor|<span style="color:black">ed.</span>]]&nbsp;[[User talk:Paine Ellsworth|<sup>put'er&nbsp;there</sup>]]&nbsp;<small>16:38, 18 February 2023 (UTC)</small>
::The request was a cleanup from a move, hence isn't limited by [[WP:NOTBROKEN]].  --- <span style="font-family: 'Verdana';"><span style="color:red"><span style="font-size:120%">'''Tbf69'''</span></span></span> [[User:Tbf69|P]]&nbsp;&bull;&#32;[[User talk:Tbf69|T]] 17:03, 18 February 2023 (UTC)
:::Good catch and thanks for the reminder ([[WP:DOFIXIT]]) – and {{edited2|edited}}. '''''[[User:Paine Ellsworth|<span style="font-size:92%;color:darkblue;font-family:Segoe Script">P.I.&nbsp;Ellsworth</span>]]'''''&thinsp;,&nbsp;[[Editor|<span style="color:black">ed.</span>]]&nbsp;[[User talk:Paine Ellsworth|<sup>put'er&nbsp;there</sup>]]&nbsp;<small>18:04, 18 February 2023 (UTC)</small>
::::Thank you!  --- <span style="font-family: 'Verdana';"><span style="color:red"><span style="font-size:120%">'''Tbf69'''</span></span></span> [[User:Tbf69|P]]&nbsp;&bull;&#32;[[User talk:Tbf69|T]] 18:09, 18 February 2023 (UTC)
:::::''my pleasure!''&nbsp;'''''[[User:Paine Ellsworth|<span style="font-size:100%;color:darkblue;font-family:Segoe Script">Paine</span>]]'''''&nbsp;&nbsp;<small>18:23, 18 February 2023 (UTC)</small>

== Template-protected edit request on 4 September 2023 ==

{{edit template-protected|Template:Infobox bridge|answered=yes}}
Change label41 "Clearance above" link from [[Structure gauge]] to [[Clearance above]] (change [[Structure gauge|Clearance above]] to just [[Clearance above]]). It is a more direct topic than the current link which is a rail specific application. [[User:Z22|Z22]] ([[User talk:Z22|talk]]) 23:25, 4 September 2023 (UTC)
: {{done}} [[User:Pppery|* Pppery *]] [[User talk:Pppery|<sub style="color:#800000">it has begun...</sub>]] 14:17, 5 September 2023 (UTC)