Template talk:Infobox bridge

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)

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)

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)

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)