Template talk:Infobox planet/Archive 8

Template-protected edit request on 25 March 2016 (addition of tisserand)
The MPC provides this value ( "Tisserand w.r.t. Jupiter"), and I've seen pages use 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

~ Tom.Reding (talk ⋅dgaf) 15:25, 25 March 2016 (UTC) PAGE ]]) 21:31, 25 March 2016 (UTC) PAGE ]]) 21:34, 25 March 2016 (UTC)
 * Red information icon with gradient background.svg Not done: please establish a consensus for this alteration before using the template. Ahecht ([[User_talk:Ahecht|'''TALK
 * I have notified WP:WikiProject Astronomy and WP:WikiProject Astronomical objects about these edit requests. --Ahecht ([[User_talk:Ahecht|'''TALK
 * 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. lovely words above which describe the issues very effectively. Perhaps you could incorporate some of it into Edit requests one day? &mdash; Martin (MSGJ · talk) 09:27, 1 April 2016 (UTC)
 * I almost responded with a blushing "piffle", but actually, rereading Edit requests makes me think you might be right . I'll be bold (later) and discuss any reversions. fredgandt 10:10, 1 April 2016 (UTC)

✅. 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)
 * 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.  R fassbind  – talk   15:26, 4 April 2016 (UTC)
 * ✅ 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, 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 (1.234 + 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:  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. Pinging to complete. ~ Tom.Reding (talk ⋅dgaf) 12:38, 4 May 2016 (UTC)

~ Tom.Reding (talk ⋅dgaf) 12:38, 4 May 2016 (UTC)
 * Yes check.svg Done Izno (talk) 12:51, 4 May 2016 (UTC)
 * ✅ 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 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  parameter: Please yea/nay/discuss so that I may submit a (hopefully) consensus edit request. ~ Tom.Reding (talk ⋅dgaf) 14:25, 11 May 2016 (UTC)
 * 1)   -> discovery_ref,
 * 2)   -> orbit_ref,
 * 3)   -> p_orbit_ref,
 * 4)   -> atmosphere_ref,
 * 5)   -> physical_ref (proposed).


 * Edit request was answered by.

~ 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)
 * Yes check.svg Done Primefac (talk) 03:51, 12 February 2017 (UTC)

Hmm... can " " be changed to " ? 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)
 * 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- usage.)  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  09:07, 12 February 2017 (UTC)
 * Did some tests. --George Ho (talk) 09:57, 12 February 2017 (UTC)
 * 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)
 * 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 ✅.  Paine Ellsworth   - put'r there –  19:54, 12 February 2017 (UTC)

Current image scale/size
The current  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 " " (which is reverted) would not work while the "sizedefault" parameter uses "225x225px" as default size. If changed to, 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).  R fassbind  – talk  05:09, 11 April 2017 (UTC)
 * Actually I've seen several comets with valid filled in mp_names.
 * There are several moons that use mp_name though, like Remus (moon), 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. 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,  R fassbind  – talk  16:03, 12 May 2017 (UTC)


 * , the documentation is missing image_size, and using either [[Image:Blah.jpg|300px]], or Blah.jpg, or Blah.jpg300px 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:Blah.jpg|300px]] or Blah.jpg. 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, 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 could enlighten us?   R fassbind  – talk  17:12, 15 May 2017 (UTC)


 * Hi, the deprecated syntax I was talking about is of course, 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.— TAnthonyTalk 19:43, 15 May 2017 (UTC)


 * thank you for your explanation. There is a large variety of images used in 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  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,   R fassbind  – 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.— TAnthonyTalk 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? <b style="color:#000">nagual</b><b style="color:#ABAB9D">design</b></b> 19:24, 6 December 2017 (UTC)


 * Scratch that. The problem's been fixed, and had nothing to do with the infobox. <b style="font:1.3em/1em Trebuchet MS;letter-spacing:-0.07em"><b style="color:#000">nagual</b><b style="color:#ABAB9D">design</b></b> 00:17, 8 December 2017 (UTC)

Doubled link Perihelion and aphelion text
Perihelion and aphelion links were changed 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)
 * , I think I fixed it. thank you. Frietjes (talk) 13:59, 5 November 2017 (UTC)
 * Sorry and thanx. -  FlightTime  ( open channel ) 15:58, 5 November 2017 (UTC)

Possible problem with 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 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)