Template talk:Infobox bridge/Archive 2

Archive 1

Archive 2

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 Kerry (talk) 03:09, 14 January 2020 (UTC)

Always link to examples of the problem you are describing. – 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
edit example 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 Dave Rave (talk) 04:44, 14 January 2020 (UTC)

@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 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 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. Kerry (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). Kerry (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 worked around the issue in a reasonable way. – 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 |coordinates=. let me know if you see any problems! Frietjes (talk) 13:45, 16 July 2020 (UTC)

@Frietjes: Was the removal of the red area outlines (for the pages with a Wikidata item linked from an OSM object) intentional? Jc86035 (talk) 17:49, 25 July 2020 (UTC)

Jc86035, this was not intentional. can you provide a link to a page where this feature was being used? Frietjes (talk) 14:12, 27 July 2020 (UTC)

@Frietjes: It used to work in the infobox documentation, since the OpenStreetMap area object for the Sydney Harbour Bridge links to the Wikidata item, and the example uses |qid=Q54495. (|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.) Jc86035 (talk) 14:27, 27 July 2020 (UTC)

Jc86035, do you know how to test if outline is available? for now, I have added |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. Frietjes (talk) 15:26, 27 July 2020 (UTC)

@Frietjes: I don't know exactly how it used to work because I didn't write the implementation; I just copied it from {{Infobox building}}. Jc86035 (talk) 15:28, 27 July 2020 (UTC)

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. 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. — Martin (MSGJ · talk) 14:22, 22 September 2020 (UTC)

Thank you for using WikidataIB so that only sourced data will be retrieved. – Jonesey95 (talk) 15:34, 22 September 2020 (UTC)

I was intending to leave that to editorial discretion on each separate article, so |onlysourced= can be set appropriately. Yes I know how contentious this can be! — Martin (MSGJ · talk) 16:46, 22 September 2020 (UTC)

Record traffic

Is it a good idea to add a "record traffic" parameter?--Александр Мотин (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. — Martin (MSGJ · talk) 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"? — Martin (MSGJ · talk) 09:02, 25 September 2020 (UTC)

Website field not working

Spiting up duplicates and span. (See Crimean Bridge) Smeagol 17 (talk) 11:11, 28 September 2020 (UTC)

Data entry error; fixed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:24, 28 September 2020 (UTC)

Thanks.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? — Martin (MSGJ · talk) 08:23, 24 September 2020 (UTC)

The code for this is now in the sandbox — Martin (MSGJ · talk) 20:30, 27 September 2020 (UTC)

And  Added — Martin (MSGJ · talk) 08:38, 30 September 2020 (UTC)

Onlysourced

As statements about bridges are unlikely to be too controversial, I am thinking about setting |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? — Martin (MSGJ · talk) 16:31, 10 October 2020 (UTC)

 Done — Martin (MSGJ · talk) 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 — Martin (MSGJ · talk) 13:10, 28 October 2020 (UTC)

Code is on the sandbox. Test cases can be seen on Template:Infobox bridge/testcases — Martin (MSGJ · talk) 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 — Martin (MSGJ · talk) 21:18, 5 December 2020 (UTC)

Multiple coordinates

After 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 {{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 {{coord}} template into a |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 {{coord}} template elsewhere? 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. — Martin (MSGJ · talk) 16:43, 24 September 2020 (UTC)

I have reverted that change and the error messages have disappeared. Sorry about not testing that properly. — Martin (MSGJ · talk) 16:55, 24 September 2020 (UTC)

@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. 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. — Martin (MSGJ · talk) 17:25, 24 September 2020 (UTC)

I have asked 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.) — Martin (MSGJ · talk) 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 {{coord}} template exists in the article but outside the infobox, so the infobox pulls coordinates from Wikidata. Pinging @Mandruss and Jc86035: do you know how to detect these duplications?

In the long run, the best fix is probably to find all articles that use {{coord}} outside of the infobox and either move it inside the infobox or remove it and use the Wikidata coordinates. This search shows all Infobox bridge articles with coordinates in Wikidata that also use the {{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 {{coord}} outside the infobox; I can probably set that up. – 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?

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. ―Mandruss ☎ 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? — Martin (MSGJ · talk) 10:09, 28 September 2020 (UTC)

I have created Category: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. This search is supposed to show articles that have an empty |coordinates= parameter and that also contain the {{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. – 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. — Martin (MSGJ · talk) 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. – 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 — Martin (MSGJ · talk) 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 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 {{coord}} somewhere else on the article, then there is no way to prevent the duplication of these coordinates. — Martin (MSGJ · talk) 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. – 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 {{coord}}, not defined in the infobox, but defined at Wikidata. If you know a way to track these, please let me know. — Martin (MSGJ · talk) 10:46, 1 October 2020 (UTC)

Maybe 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. – 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 |fetchwikidata=coordinates — Martin (MSGJ · talk) 16:38, 1 October 2020 (UTC)

And 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. – Jonesey95 (talk) 17:00, 1 October 2020 (UTC)

I have cleared out all those articles, so they should all be displaying coordinates now — Martin (MSGJ · talk) 21:11, 1 October 2020 (UTC)

@MSGJ: The duplicate title coordinates were caused by a bug in the WikidataIB module. It should be fixed now. See discussion at Module talk:WikidataIB#Wrong default for display parameter passed to Coord template by getCoords. Kaldari (talk) 01:16, 9 December 2020 (UTC)

Indeed. The getCoords function in WikidataIB always used a default of "inline, title" when no |display= was set, although that could have been overridden from any infobox design by supplying |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. --RexxS (talk) 04:54, 9 December 2020 (UTC)

@Kaldari and 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 Deor unhappy. Is there any way that the coordinates defined from WikidataIB can be supressed if there is already a {{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 |fetchwikidata=coordinates when an editor or bot has confirmed there is no {{coord}} template present.) — Martin (MSGJ · talk) 14:17, 9 December 2020 (UTC)

@MSGJ: A better solution would probably be to remove the extra {{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? Kaldari (talk) 16:30, 9 December 2020 (UTC)

(edit conflict) @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 {{coords}} were already in an article and someone added a local value to the infobox like this: |coordinates = {{coord|40.3128|-79.8283}}}} (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 {{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? --RexxS (talk) 16:33, 9 December 2020 (UTC)

• {{#invoke:String2 |findpagetext |text=Youghiogheny}} → 23502
• {{#invoke:String2 |findpagetext |text=Youghiogheny |nomatch=not found}} → 23502
• {{#invoke:String2 |findpagetext |text=Youghiogheny |title=Boston Bridge |nomatch=not found}} → 296
• {{#invoke:String2 |findpagetext |text=river |title=Boston Bridge |nomatch=not found}} → not found
• {{#invoke:String2 |findpagetext |text=[Rr]iver |title=Boston Bridge |plain=false |nomatch=not found}} → 309
• {{#invoke:String2 |findpagetext |text=%[%[ |title=Boston Bridge |plain=f |nomatch=not found}} → 294
• {{#invoke:String2 |findpagetext |text=%{%{[Cc]oord |title=Boston Bridge |plain=f |nomatch=not found}} → 2470

The search is case-sensitive, so you need to use Lua pattern matching to find river or River. The last one finds {{coord and {{Coord. --RexxS (talk) 18:41, 9 December 2020 (UTC)

Hey ...

• 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.
• 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.
• 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.
• 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 {{coord}} to create the titlebar and the infobox template to deal with the infobox?

— Martin (MSGJ · talk) 22:13, 9 December 2020 (UTC)

It is normal for infoboxes to contain redundant information – 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 {{coord}} in the article source text by writing something like this:

• | data1 = {{#if:{{findpagetext |text=%{%{[Cc]oord |plain=false}} ||{{#invoke:WikidataIB|getCoords|name=coordinates|fetchwikidata={{{fetchwikidata|}}}|display={{{display|}}}|{{{coordinates|}}}}} }}

That would suppress any coordinate display in the infobox if there was a {{coord}} in the article text. If there was no {{coord}} in the article text, it would allow setting a |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. --RexxS (talk) 22:50, 9 December 2020 (UTC)

@Deor: do you think it would be okay if the {{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 — Martin (MSGJ · talk) 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. — Martin (MSGJ · talk) 11:41, 11 December 2020 (UTC)

If the coordinates in the infobox are set for inline display and the ones in the {{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.) 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. --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 — Martin (MSGJ · talk) 21:54, 11 December 2020 (UTC)

In Template:Infobox bridge/sandbox I've added a parameter |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 --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 {{url|https://www.example.com}} is added it produces: www.example.com www.example.com www<wbr/>.example<wbr/>.com]</span>]

You can see this in an example I made on my sandbox and in the page Swing Bridge, River Tyne where I first came across this. --Voello _talk 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 {{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. — Martin (MSGJ · talk) 22:46, 28 October 2020 (UTC)

This is related to changes to Module:WikidataIB. I have posted there. – 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 {{url}} the documentation should be updated (if it's not fixed) as for |website= it currently states "URL to the bridge's website; enclose within {{URL}}". --Voello _talk 11:46, 29 October 2020 (UTC)

The documentation has recommended the use of {{URL}} for at least 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. – 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 — Martin (MSGJ · talk) 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 — Martin (MSGJ · talk) 19:55, 4 December 2020 (UTC)

Hopefully this is now fixed — Martin (MSGJ · talk) 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! — Martin (MSGJ · talk) 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 --RexxS (talk) 14:49, 3 January 2021 (UTC)

Didn't realise this template was so cutting edge! — Martin (MSGJ · talk) 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? — Martin (MSGJ · talk) 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". – 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. — Martin (MSGJ · talk) 17:49, 5 January 2021 (UTC)

Perhaps I should be a bit more nuanced in stating my preference. First, I will refer you to 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. – 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. |fetchwikidata=ALL. — Martin (MSGJ · talk) 22:14, 8 January 2021 (UTC)

You can set the sourcing on a per-field basis by adding |osd=y or |osd=n 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 |osd={{{onlysourced|y}}} and |osd={{{onlysourced|n}}} instead. --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 |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 |fetchwikidata= does not include length, then it would only be fetched if it was sourced. — Martin (MSGJ · talk) 20:32, 9 January 2021 (UTC)

Inception

Currently we are mapping inception (P571) to "Opened". I am wondering whether it would map more accurately to "Construction start" which is currently defined using the {{{begin}}} parameter. — Martin (MSGJ · talk) 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? — Martin (MSGJ · talk) 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. --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 inception (P571) for "opened" and date of official opening (P1619) for "inaugurated". For construction dates, the best I have seen is:

significant event	construction edit start time 5 January 1933 end time 19 April 1937 ▼ 0 reference + add reference
		+ add value

That comes from Golden Gate Bridge (Q44440) — Martin (MSGJ · talk) 22:08, 8 January 2021 (UTC)

That's okay to retrieve:

{{wdib|ps=1|qid=Q44440|P793|qual=DATES|qdf=mdy}} → construction (January 5, 1933 – April 19, 1937)

{{wdib|ps=1|qid=Q44440|P793|qual=DATES|qdf=mdy|qo=y}} → January 5, 1933 – April 19, 1937

The latter returns qualifiers only (|qo=yes if you just want the values. We use significant event (P793) a lot for telescopes and observatories because it avoids having to create a new property for each possible event. --RexxS (talk) 01:46, 9 January 2021 (UTC)

Thanks.

1. Why does the date default to year only (the documentation says the default is dmy)?

   {{wdib|ps=1|P793|qual=P580|qid=Q44440|qo=y}} → 5 January 1933

2. And how to remove that dash at the end? (The start date and end date are kept in separate field.) — Martin (MSGJ · talk) 20:52, 9 January 2021 (UTC)

The date defaults to year only for qualifiers because there were complaints that the output from things like capital of (P1376) for Geneva (Q71) with full dates was too much for an infobox field:

{{wdib |P1376 |fwd=ALL |osd=no |qid=Q71 |qual=DATES}} → Canton of Geneva (1815–), Léman (1798–1813), Republic of Geneva (1534–1798), Republic of Geneva (1813–1815) 

Qualifiers usually only want the year, but setting |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 highest point (P610) for France (Q142):

{{wdib |P610 |fwd=ALL |osd=no |qid=Q142 |qual=P2044, P1326, DATES}} → Mont Blanc (4,808.72 metre, 1860–), Barre des Écrins (4,102 metre, before 1860) 

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 |qualifiersonly= is set and there is only only one date to return. I can see that you've already figured out to use |qdf= for those cases. I apologise that I don't keep the documentation up to date. I'll try to do better. --RexxS (talk) 23:12, 9 January 2021 (UTC)

Don't apologise! That's very helpful — Martin (MSGJ · talk) 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= ###

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. MB 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 |embed=yes is used? — Martin (MSGJ · talk) 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. MB 14:18, 26 July 2022 (UTC)

Image and map widths

@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? ɱ (talk) 21:22, 12 July 2022 (UTC)

I continue to object to this default image sizing in infoboxes, per MOS:IMGSIZE (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 (Ɱ'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. – 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: "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. ɱ (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 frameless. If the module is not used, WP:INFOBOXIMAGE recommends using frameless, 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 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. – 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. ɱ (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. – 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. ɱ (talk) 16:05, 13 July 2022 (UTC)

I am not ignoring anything, and I am engaging sincerely. WP:INFOBOXIMAGE clearly says to use Module:InfoboxImage, which defaults to frameless, 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. – 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 — Martin (MSGJ · talk) 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. ɱ (talk) 16:09, 13 July 2022 (UTC)

frameless 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. – 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. ɱ (talk) 16:14, 13 July 2022 (UTC)

@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. ɱ (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 upright=1.14 (1.14=250px/220px), but it would require testing. The idea would be to make it so that the infobox image default of frameless 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. – 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? ɱ (talk) 17:14, 13 July 2022 (UTC)

@Jonesey95: Do you have an update on this, or do you know anyone who can assist with it? ɱ (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?Naraht (talk) 17:16, 8 September 2022 (UTC)

It appears that all |map_*= parameters were 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 |coordinates= may be needed. – 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.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 Naraht (talk) 17:16, 9 September 2022 (UTC)

Should be fixed now. ɱ (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?

Naraht (talk) 17:46, 9 September 2022 (UTC)

|pushpin*= are related to the old map parameters and can be removed. All of the |mapframe-*= parameters use hyphens, not underscores, AFAICT. – Jonesey95 (talk) 18:18, 9 September 2022 (UTC)

Getting rid of the pushpin ones as well.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?Naraht (talk) 17:13, 9 September 2022 (UTC)

Yes, they are part of header85, as part of #invoke:Infobox mapframe. ɱ (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.Naraht (talk) 17:34, 9 September 2022 (UTC)

The correct parameter was |mapframe-zoom= (note the hyphen). – 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.Naraht (talk) 18:46, 9 September 2022 (UTC)

Good call. Please check Category:Pages using duplicate arguments in template calls when you are done, in case there was already a mapframe-* parameter present. – Jonesey95 (talk) 19:01, 9 September 2022 (UTC)

Complete

At this moment Category:Pages using infobox bridge with unknown parameters is emptyNaraht (talk) 04:04, 11 September 2022 (UTC)

Nicely done. Thanks for this gnoming. – 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 Frank J. Wood Bridge 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. — Martin (MSGJ · talk) 19:46, 22 September 2022 (UTC)

Gotcha, thank you! Jake-jakubowski (talk) 19:54, 22 September 2022 (UTC)