Template talk:Infobox planet/Archive 8

Archive 5

Archive 6

Archive 7

Archive 8

Archive 9

Archive 10

Archive 11

Template-protected edit request on 25 March 2016 (addition of tisserand)

The MPC provides this value (MPC "Tisserand w.r.t. Jupiter"), and I've seen pages use {{Infobox|child=yes}} to incorporate it (i.e. (4953) 1990 MU), or as part of an unrelated parameter (i.e. 118401 LINEAR). I haven't seen non-Jupiter Tisserand parameters on the MPC db nor on MP pages, so |tisserand= seems appropriate as the most common reference point (similar to |moid= referring to Earth's MOID with an asteroid).

Since Tisserand's parameter is a function of orbital elements semimajor axis, eccentricity, and inclination, including it in header20 (orbital characteristics) along with these elements, and either above |moid= (label/data45) or after |neptune_moid= (label/data52) seems most appropriate, using

| label45 = Jupiter [[Tisserand's parameter|Tisserand parameter]]

| data45 = {{{tisserand|}}}

  ~ Tom.Reding (talk ⋅dgaf)  15:25, 25 March 2016 (UTC)

Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. Ahecht (TALK
PAGE) 21:31, 25 March 2016 (UTC)

I have notified WP:WikiProject Astronomy and WP:WikiProject Astronomical objects about these edit requests. --Ahecht (TALK
PAGE) 21:34, 25 March 2016 (UTC)

Support: Looks like a parameter that is worth adding. There is no problem with a parameter that is only occasionally used; establishing consensus for adding every valid parameter is overkill IMO, it doesn't affect articles where it isn't used. I think I've also seen a Neptune Tisserand's parameter a few times, so I think it worth separating these two. --JorisvS (talk) 10:34, 26 March 2016 (UTC)

As template editors, we may have no general knowledge of the subject/arena the template is utilised by/in (we just get a heads up that someone has made a request), and especially where a WikiProject is involved, it's good to get community feedback about the requested change(s). Unfortunately, too often, the first anyone knows of a change is after it's happened, and the surprise can lead to immediate tension. Asking for consensus serves to involve, educate and inform all interested parties, and reduces the potential for friction. There may also be other concerns the quest for input unearths, which could have a significant effect on the technically best procedure i.e. it's possible that other factors should be included or considered. fredgandt 15:45, 26 March 2016 (UTC)

I've disabled the request. Please reactivate when ready. @Fred Gandt: lovely words above which describe the issues very effectively. Perhaps you could incorporate some of it into Wikipedia:Edit requests one day? — Martin (MSGJ · talk) 09:27, 1 April 2016 (UTC)

I almost responded with a blushing "piffle", but actually, rereading Wikipedia:Edit requests#Making requests makes me think you might be right MSGJ. I'll be bold (later) and discuss any reversions. fredgandt 10:10, 1 April 2016 (UTC)

• Support: if it conveys some useful information, then sure why not? Praemonitus (talk) 22:14, 1 April 2016 (UTC)
• Support: sure, unconditional support. I think Tom should receive a template admin status. I know he easily masters the tpl-syntax and, in this way, we would have someone who's allowed to edit the subject he knows about. Rfassbind – talk 15:26, 4 April 2016 (UTC)

@Tom.Reding:  Done. Looks like a pretty good consensus here. Please update the documentation at Template:Infobox planet/doc. --Ahecht (TALK
PAGE) 20:18, 4 April 2016 (UTC)

 Updated doc Thank you!   ~ Tom.Reding (talk ⋅dgaf)  21:01, 4 April 2016 (UTC)

Time of perihelion/astron

I wanted to add the times of last and next perihelion, as existing in Template:Infobox comet, then I saw there is already a time_periastron parameter, which applies the same concept to exoplanets. So I tried to make the template generic by replacing long_periastron and time_periastron with long_peri and time_peri parameters, which are then treated similarly to the existing arg_peri parameter: substituting the correct suffix (-helion, -astron, -gee, etc.) depending on the orbited body. Please see my proposed changes in the sandbox version, supported by a new test case on comet 67P/Churyumov–Gerasimenko. These changes have the desired effect on 67P and they don't seem to break anything in the other test cases, so I would like to get consensus to apply them to the official template version.

However the listed test cases do not use time_periastron and I don't know how to search for usage of the time_periastron and long_periastron parameters in pages that make use of this template, in order to change the parameter names in them. Besides, it seems that exoplanets now use the Planetbox series of templates, so perhaps this Infobox planet template could be simplified by excluding exoplanets and applying only to solar system bodies. Help and comments welcome! — JFG ^talk 00:37, 29 March 2016 (UTC)

Support for dynamic peri/apo headings using |apsis=, as long as they're carefully implemented and all |peri...= and |apo...=/|aphelion= parameters are truncated to |peri= and |apo=, respectively, and made to work with |apsis=. It seems intuitive to use.   ~ Tom.Reding (talk ⋅dgaf)  17:26, 3 April 2016 (UTC)

Carefully reading what you wrote, it seems that we agree: I suggest having a generic |time_peri= parameter, and using |apsis= to specify the suffix. Default would be "-helion", as most catalogued objects do orbit the Sun. Same treatment for |long_peri=. So, could you change your !vote to "Moderate support" or some such? — JFG ^talk 17:54, 1 April 2016 (UTC)

Changed my vote+comments to be more clear.

This would imply the existence of the non-existent term apohelion (|apo=1.234 + |apsis=helion), though only to the template editor, and not at all to the general reader, so I think the simplification is worth doing.   ~ Tom.Reding (talk ⋅dgaf)  18:21, 26 April 2016 (UTC)

Comment: insource:/time_periastron/ can be used in WP search to find text in page-source, i.e. infoboxes. That search finds 29 pages.   ~ Tom.Reding (talk ⋅dgaf)  14:58, 30 March 2016 (UTC)

Thanks for the tip! — JFG ^talk 17:54, 1 April 2016 (UTC)

Support. I can't see any value in having a separate Infobox comet when the Infobox planet is used for everything else. --JorisvS (talk) 18:23, 4 April 2016 (UTC)

Template-protected edit request on 4 May 2016 (addition of label_width)

Please update the live version with the changes made in the sandbox since the last sync on 13:02, 26 April 2016‎ (diff), which only includes the addition of |label_width= with a default size of 11em, per discussion at WT:ASTRO#Infobox planet's inner margins. Pinging RexxS to complete.   ~ Tom.Reding (talk ⋅dgaf)  12:38, 4 May 2016 (UTC)   ~ Tom.Reding (talk ⋅dgaf)  12:38, 4 May 2016 (UTC)

Done Izno (talk) 12:51, 4 May 2016 (UTC)

 Updated doc. Thanks!   ~ Tom.Reding (talk ⋅dgaf)  13:23, 4 May 2016 (UTC)

Template-protected edit request on 14 May 2016 (addition of physical_ref)

Per WT:ASTRO#Please vote on the new {{Infobox planet}} parameter, physical_ref, as a formality & for record/statistic keeping purposes, I'm adding the recently-completed request:

To compliment the other 4 sections that have their own *_ref parameter:

1. Discovery -> |discovery_ref=,
2. Orbital Characteristics -> |orbit_ref=,
3. Proper orbital elements -> |p_orbit_ref=,
4. Atmosphere -> |atmosphere_ref=,
5. Physical characteristics -> |physical_ref= (proposed).

Please yea/nay/discuss so that I may submit a (hopefully) consensus edit request.   ~ Tom.Reding (talk ⋅dgaf)  14:25, 11 May 2016 (UTC)

Edit request was answered by Primefac.

  ~ Tom.Reding (talk ⋅dgaf)  15:22, 14 May 2016 (UTC)

Template-protected edit request on 12 February 2017

I added "image_upright" in the sandbox. I plan to change an image scale in some articles. I hope the addition doesn't cause errors. George Ho (talk) 01:06, 12 February 2017 (UTC)

Done Primefac (talk) 03:51, 12 February 2017 (UTC)

Hmm... can "sizedefault=225x225px" be changed to "sizedefault=frameless? Seems to be interfering with the "upright". Update: Made some changes. George Ho (talk) 04:12, 12 February 2017 (UTC); edited. 04:14, 12 February 2017 (UTC)

@George Ho: Needs a WP:TESTCASES page showing what result that will have in various configurations. (Or rather the test-cases page needs examples of what this will fix and that it does so; I guess the extant examples at Template:Infobox planet/testcases are sufficient indication that it doesn't break non-upright usage.)  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:07, 12 February 2017 (UTC)

@SMcCandlish: Did some tests. --George Ho (talk) 09:57, 12 February 2017 (UTC)

@George Ho: I'm running out of steam for today. The markedly-larger-image effect: Is that only going to appear with intentional usage of this new feature? I think there'd be a revolt if this changed the appearance of any currently installed infoboxes that are not using it that feature. If these changes won't do that to them, then this appears to be "good to go".  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:52, 12 February 2017 (UTC)

To editor George Ho: I previewed the sandbox in some articles, including Earth, and the sandbox version made no difference in those ibox images. Does this mean that to implement your changes, you will have to set about making changes to individual-article ibox images? (Noted that you did this on the testcases page)  Paine Ellsworth  - put'r there – 19:04, 12 February 2017 (UTC)

Oh... I have been using the "400px" user preference. It's not easy to tell a difference for those using the default "220px" user setting. Now I see one concern, maybe someone here can undo the edit. I realize a consensus is needed. George Ho (talk) 19:26, 12 February 2017 (UTC); edited. George Ho (talk) 19:27, 12 February 2017 (UTC)

Okay  Done.  Paine Ellsworth  - put'r there – 19:54, 12 February 2017 (UTC)

Current image scale/size

The current sizedefault= is "225x225px". Per WP:IMGSIZE, there must a good reason for using forced width, "225x225px" and/or "image_size" parameter, which is still used as alternative. Maybe the infobox size or trying to respect the article layout? Right now, I'm using "400px" as my preference, yet the current setup does not allow me to view an image at 400px. The "image_upright" (which is reverted) would not work while the "sizedefault" parameter uses "225x225px" as default size. If changed to frameless, the appearance of images would be affected in pages that use this template. Nevertheless, users' preferences should be respected. --George Ho (talk) 22:03, 12 February 2017 (UTC)

Template-protected edit request on 10 April 2017 (change mp_name to mpc_name)

Currently, |mp_name= populates the "MPC Designation" infobox line-item. |mpc_name=, however, 1) matches the displayed text more accurately than |mp_name=, 2) is more intuitive than |mp_name=, and 3) is less likely to be mistaken for an alias of |name= to more-casual editors.   ~ Tom.Reding (talk ⋅dgaf)  15:57, 10 April 2017 (UTC)

I've made |mpc_name= a temporary alias to |mp_name=. I'll let this stew for a few days and then (if no reasonable dissent) I plan on changing all instances of |mp_name= to |mpc_name=, leaving |mp_name= as an alias to |mpc_name= for a period of backwards compatibility. After the change, I'll update the TemplateData section.   ~ Tom.Reding (talk ⋅dgaf)  16:00, 10 April 2017 (UTC)

Seems OK to me. Thank you. I presume those comet articles that use this template remain unaffected (also, there shouldn't be any exoplanets using this template with this parameter by now, but I could be wrong). Rfassbind – talk 05:09, 11 April 2017 (UTC)

Actually I've seen several comets with valid filled in |mp_name=s.

There are several moons that use |mp_name= though, like Remus (moon), |mp_name=S/2004 (87) 1, which I can't verify via the MPC b/c the search function crashes (looks like an input-sterilization problem)...   ~ Tom.Reding (talk ⋅dgaf)  14:51, 11 April 2017 (UTC)

Good job, thanks! — JFG ^talk 17:32, 11 April 2017 (UTC)

MP infobox > parameter "image_size"

Discussion copied from user talk page as relevant to this template

Most minor planet articles with an image in their infobox should have a parameter |image_size= to define the size of the image. Currently, most non-default image sizes are defined together with the image-path in parameter |image=, e.g. as [[File:Vesta_in_natural_color.jpg|260px]]. Also see this edit that fixed the issue. If you want to do the amendments, please do so, otherwise I'll do them in the weeks to come. Best, Rfassbind – talk 16:03, 12 May 2017 (UTC)

Rfassbind, the {{Infobox planet}} documentation is missing |image_size=, and using either |image=[[Image:Blah.jpg|300px]], or |image=[[File:Blah.jpg|300px]], or |image=Blah.jpg|image_size=300px works.

I'll add |image_size= to the documentation, leave it for a week or so, then go through the ~447 MPs I found that contain |image=[[Image:Blah.jpg|300px]] or |image=[[File:Blah.jpg|300px]]. Some of those 447 have additional parameters after the pixel size; I won't touch those and will put them in a shortlist for manual completion.   ~ Tom.Reding (talk ⋅dgaf)  14:30, 15 May 2017 (UTC)

Actually, looking more closely at the documentation, I'm not comfortable making such a change because the pixel-size-in-image format is the prevailing format for not just |image=, but |symbol= & |orbit_diagram= & the top-most text inside the infobox examples, and |image_size= doesn't appear anywhere in the doc, and not using |image_size= doesn't break anything.   ~ Tom.Reding (talk ⋅dgaf)  14:51, 15 May 2017 (UTC)

I based this post on TAnthony, who described this pixel-size-in-image format as a "deprecated infobox image syntax" (see example edit). I think he knows what he is doing (although he did not provide any link to a policy where this is stated clearly). My intention is to proactively add |image_size= in order to keep the customized image sizes before they are lost, but if the pixel-size-in-image format is not deprecated than, of course, this is not needed.

Maybe @TAnthony: could enlighten us? Rfassbind – talk 17:12, 15 May 2017 (UTC)

Hi, the deprecated syntax I was talking about is of course |image=[[File:Example.jpg]], not specifically the custom sizing. The use of this syntax in the |image= parameter of infoboxes places those articles into the maintenance category Category:Pages using deprecated image syntax. When I first started these "corrections", we were only dealing with specific infoboxes, like {{Infobox book}}. In that particular case, custom image sizes are unnecessary 99% of the time, as infoboxes have a default image size when using the bare filename, and the image proportions for book covers are pretty standard. More recently however, the implementation of bare filename syntax to Module:InfoboxImage has basically affected every infobox template, and we are finding that some of these templates, like {{Infobox military conflict}} and {{Infobox election}}, need specific updates or have non-standard image sizing that needs to be taken into account. With this in mind, I've been preserving custom sizing most of the time, in particular for templates with which I'm unfamiliar. The |symbol= in {{Infobox planet}} is not currently detected by the module change, but it looks like a specific image size parameter for that should be created in this template in anticipation of a future time when it is.

In the case of my edit used as an example above, I did remove the 250px sizing of the image because it seemed unnecessary to me as marginally different from the default. I did put it back with |image_size= after Rfassbind's objection, and this partially informed my preserving custom sizing moving forward. Still, if {{Infobox planet}} has a default size, I'm not sure why we are sizing standardly-shaped images. Per WP:IMAGESIZE we should not be using fixed custom image sizes, but rather relying on user image size defaults (primarily for accessibility). I was under the impression, though, that |image_size= was already available in the majority of infobox templates, but the gradual correction of this syntax is revealing many templates in which it is not.— TAnthony^Talk 19:43, 15 May 2017 (UTC)

@TAnthony: thank you for your explanation. There is a large variety of images used in {{Infobox planet}} that have a completely different aspect ratio. A custom-sized image might be also relevant for an article's layout, as the default width of {{Infobox planet}} is rather small (in my opinion), and the number of displayed data can make it very long (and even longer if the size of certain images is not reduced (e.g. see 9906 Tintoretto vs. 9921 Rubincam). To me, it seems necessary to preserve any custom size whenever possible. My question: is it better to use |image_size= rather than the pixel-size-in-image format, in order to prevent the loss of such defined custom sizes due to future mass-edits? Which one is the better syntax in your opinion? As for the symbol-images, sorry, I have no opinion (only a very small fraction has them, while an infobox-image might be available to thousands of minor planets in the future). Best, Rfassbind – talk 18:48, 18 May 2017 (UTC)

Sorry Tom.Reding if this discussion on your talk page is becoming bothersome! Rfassbind, |image_size= is really the only choice, since what you call the "pixel-size-in-image format" is deprecated. I've just created an AWB settings file to run through the transclusions of {{Infobox planet}} so over the next few days/weeks I will update the syntax and preserve the hardcoded sizes. FYI, |symbol= and |orbit_diagram= are not enabled for bare filenames yet anyway, so I will update only |image=. I'll make a note and at some point I will have this template looked at for updating. Thanks.— TAnthony^Talk 21:44, 18 May 2017 (UTC)

Add synodic rotational period

Can we add a Synodic period of rotation, i.e. synodic_day? This seems at least as important as sidereal day since it represents the average hours of daylight from a planet's surface. Currently there is a synodic_period for revolution, and sidereal_day for rotation. It can be computed by the sidereal_period and sidereal_day, but not trivially, needing reciprocal differences. Tom Ruen (talk) 16:32, 31 August 2017 (UTC)

Issues with CSS clear

This infobox (or perhaps it's all infoboxes) seems to have the CSS clear property set to both, and is causing issues at ʻOumuamua, where left-aligned images are being pushed down the page. Is there any way to overcome this? nagualdesign 19:24, 6 December 2017 (UTC)

Scratch that. The problem's been fixed, and had nothing to do with the infobox. nagualdesign 00:17, 8 December 2017 (UTC)

Doubled link Perihelion and aphelion text

Perihelion and aphelion links were changed [1] by User:FlightTime which is doubling up the labels! I don't have edit access to correct this. Tom Ruen (talk) 05:31, 5 November 2017 (UTC)

Tomruen, I think I fixed it. thank you. Frietjes (talk) 13:59, 5 November 2017 (UTC)

@Tomruen and Frietjes: Sorry and thanx. - FlightTime (open channel) 15:58, 5 November 2017 (UTC)

Possible problem with {{{image_size}}} handling

Here, a problem was reported on the talk page of an article using this template. The problem was described as, "infobox > lead-image is not displayed correctly (in chrome/ubuntu); adding param image_size seems to fix the problem". I'm just passing this info on.

I do note that the template code here for {{{image_size}}} handling differs from {{infobox person}} which I took a quick look at for comparison. Perhaps a need for some standardization is indicated here. Wtmitchell (talk) (earlier Boracay Bill) 23:03, 22 November 2017 (UTC)