Template talk:Starbox begin

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
WikiProject iconAstronomy: Astronomical objects Template‑class
WikiProject iconThis template is within the scope of WikiProject Astronomy, which collaborates on articles related to Astronomy on Wikipedia.AstronomyWikipedia:WikiProject AstronomyTemplate:WikiProject AstronomyAstronomy articles
TemplateThis template does not require a rating on Wikipedia's content assessment scale.
Taskforce icon
This template is supported by WikiProject Astronomical objects, which collaborates on articles related to astronomical objects.

Decimal exponent units for log g[edit]

Would it be necessary to include dex as an alternate unit for log g? This unit is sometimes used (e.g. Tannock et al 2103.01990) and it would be useful to have a conversion between dex and cgs. Nrco0e (talk · contribs) 18:32, 12 March 2021 (UTC)[reply]

dex isn't a unit as such. It is an abbreviation of sorts for decimal exponent, indicating that the number is the decimal exponent of the actual value. Looked at another way it is the logarithm of the value. Technically, such numbers are unitless but they are often followed by an indicator of the system of units used for the original value, since the logarithm of a value in light years is obviously different fro the logarithm of a number of miles. log(g) for the surface gravity of a star is almost universally the logarithm of the cgs value, ie. in cm/s2, perhaps not the units you'd expect. This usage is explained at surface gravity. dex units in general are not well-explained anywhere I could find in WP. There is decimal exponent which redirects to common logarithm but it doesn't say anything about "dex" exactly. There is dex, but that dab page doesn't say anything either. Lithopsian (talk) 21:02, 12 March 2021 (UTC)[reply]

Template-protected edit request on 9 July 2021[edit]

Please remove the interlanguage link [[fr:Modèle:Astrobox catalogue]] in Template:Starbox catalog. It points to a deleted target. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 09:43, 9 July 2021 (UTC)[reply]

 Done Primefac (talk) 10:05, 9 July 2021 (UTC)[reply]

Template-protected edit request on 15 July 2021[edit]

In Template:Starbox detail, please remove the two interlanguage links at the bottom of the template. [[fr:Modèle:Starbox détail]] points to a deleted template and [[es:Plantilla:Starbox detail]] redirects to a template with different function that is linked to the appropriate English template by wikidata. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 10:49, 15 July 2021 (UTC)[reply]

 Done Terasail[✉️] 11:37, 15 July 2021 (UTC)[reply]
To editor ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ: also removed from the template documentation page. And thank you for the good catch! P.I. Ellsworth  ed. put'r there 11:48, 15 July 2021 (UTC)[reply]

Template-protected edit request on 31 August 2021[edit]

The {{starbox reference}} template generates urls to several common astronomical databases. It uses the now virtually-obsolete http:// prefixes. Although many websites automatically redirect requests to the secure https:// equivalent, some, including Simbad do not. This can cause warnings in some browsers, and the websi page may not even display. Please change each instance of "http://" to "https://". Lithopsian (talk) 18:35, 31 August 2021 (UTC)[reply]

 Done Primefac (talk) 18:40, 31 August 2021 (UTC)[reply]

Template-protected edit request on 15 January 2022[edit]

For {{Starbox astrometry}}, the documented 'pm_footnote2' parameter, which references the second set of proper motion rows, has not been implemented. It should update the 'prop_mo_ra2' and 'prop_mo_dec2' rows in the same manner as the 'pm_footnote' parameter updates the 'prop_mo_ra' and 'prop_mo_dec' rows. Thank you. Praemonitus (talk) 22:55, 15 January 2022 (UTC) Praemonitus[reply]

 Done Primefac (talk) 10:05, 16 January 2022 (UTC)[reply]

Exoplanet Encyclopedia[edit]

There's a problem with Exoplanet Encyclopedia reference. I guess they changed the structure of the website at some point. Unfortunately, they no longer have pages for the stars, but for the planets. For example, HR 8799d is http://exoplanet.eu/catalog/hr_8799_d/ (note also that they are still using http:// not https://). I'm not sure the best way to deal with this. I guess this reference should be removed from the star infobox and added to the planet ones instead. Although this is a bit awkward since the other references are all for star. AstroMark (talk) 20:23, 21 January 2022 (UTC)[reply]

Template-protected edit request on 1 April 2022[edit]

Replace the current version of Template:Starbox astrometry (that talk page redirects here) with the current contents of User:RandomCanadian/sandbox2. This adds a dist_ref parameter to add a reference for the distance at the appropriate place (diff of the difference). Cheers, RandomCanadian (talk / contribs) 22:04, 1 April 2022 (UTC)[reply]

References between the numeric value and the units is a known issue throughout the starboxes, but consistency is probably more valuable than trying to make it "right" for just one case - see pm_footnote and parallax_footnote which intentionally place the reference before the units. I have fixed the documentation page, there is no dist_footnote2. Lithopsian (talk) 13:06, 3 April 2022 (UTC)[reply]
I've looked at the other starbox templates, and none of them seem to be having the refs at the wrong place. If it's a known issue with this one, then it's a relatively easy fix, and if the footnote parameters are explicitly present, they might as well be at the right place - see diff. @Paine Ellsworth: (or somebody else if they notice this first): same routine; replace current version of Template:Starbox astrometry with contents of my sandbox (i.e. diff linked above). Cheers, RandomCanadian (talk / contribs) 17:34, 3 April 2022 (UTC)[reply]
 Done. P.I. Ellsworth - ed. put'r there 19:27, 3 April 2022 (UTC)[reply]
Take a look at any star article instead of code-reading, and maybe we can stop making piecemeal changes that aren't really improving these templates. Try Sirius, it has a fairly complete set of fields. At the top of the template, it says "Before making modifications to this template, please discuss the proposed changes on the WikiProject Astronomical objects talk page. Thank you.", that's so that these questions can be ironed out before they hit thousands of star articles. If you do that, you *will* get feedback, but that's a good thing, right? Lithopsian (talk) 21:08, 3 April 2022 (UTC)[reply]
@Lithopsian: As regards the astrometry box, Sirius was an instance were the existing parameter was unused when it should have been used... Now it shows that an additional parameter might be necessary for radial velocity (and really, that's not something complex to add - you literally add {{{whatever_footnote|}}} at the appropriate place after the unit). The rest shows this was just horribly designed to start with - it might be far simpler to just put the unit abbreviations in with the description (i.e. have "Temperature (K) // [whatever][ref]" instead of the current "Temperature // [whatever][ref](K)". RandomCanadian (talk / contribs) 21:17, 3 April 2022 (UTC) i.e. this what I'm thinking about. RandomCanadian (talk / contribs) 21:27, 3 April 2022 (UTC)[reply]

Have notified project members of this and the next (below) discussions. P.I. Ellsworth - ed. put'r there 00:00, 4 April 2022 (UTC)[reply]

Horribly-designed or not, it is what we have and thousands of articles used it. Any wholesale re-design would likely need an associated bot to edit the articles and nobody has been ready to take that on. There was an attempt a few years back to rewrite the multiple starboxes along the lines of a simplified infobox, but after consideration of all the edge cases (eg. multiple instances of one starbox template such as {{starbox detail}} or {{starbox orbit}} within the starbox begin/end nest) and a lack of agreement about which fields could be dropped, it all ran into the long grass. There are some instances where multiple values (eg. for a binary or variable star) are placed in one starbox field, with all except the last one having to include the units, and some instances of fields that need units but where the template doesn't provide them (eg. period_unitless in {{starbox orbit}}). Very messy - take a look at Eta Carinae for examples, but like I said: if you're not going to fix them all then making some of them different isn't really helping. In related news, the {{odlist}} template intended to be used inside {{starbox reference}} has problems with placing references after the commas, although it is relatively uncommon to have references nested inside the template. See Antares for an example. Lithopsian (talk) 11:08, 4 April 2022 (UTC)[reply]
Redesigning starbox detail to avoid the ref issue and have minimal changes was a rather minor affair (which would not require a bot at this time), see User:RandomCanadian/sandbox3 (the only parameter that's still tricky is the age, but for consistency I guess I could do like the others). RandomCanadian (talk / contribs) 17:58, 4 April 2022 (UTC)[reply]
@Lithopsian: ... nobody has been ready to take that on - false, as a merger/replacement with {{infobox star}} was rejected a few years back, despite a successful merger of the planetbox begin series into {{infobox planet}} at a similar time. I am more than capable (and willing) to have my bot perform the merger, but no one wants it (apparently) despite starbox's many shortcomings. Primefac (talk) 07:38, 5 April 2022 (UTC)[reply]
If you can make wholesale improvements, then propose the new design at Wikipedia talk:WikiProject Astronomical objects. I can see some issues ahead with that layout, for example in {{starbox orbit}}, but with a bit of thought maybe it can be all worked through. Better yet if it doesn't need a bot. I did think that we could do without a bot by making the existing templates become wrappers for a new set of starboxes, but that's probably going to be more trouble in the long run. Lithopsian (talk) 14:17, 5 April 2022 (UTC)[reply]

Template-protected edit request on 3 April 2022[edit]

This template uses <small> tags which reduces font size in already-reduced infobox text, not allowed per MOS:SMALL. MB 18:42, 3 April 2022 (UTC) MB 18:42, 3 April 2022 (UTC)[reply]

 Done. To editor MB: there are no "small" tags in this template, but this is a centralized talk page for other templates. There were ten sets of "small" tags in the {{Starbox astrometry}} template, so I removed them. Did you mean that template? or did you mean a different template? P.I. Ellsworth - ed. put'r there 19:34, 3 April 2022 (UTC)[reply]
Paine Ellsworth, actually, I got here from {{Starbox observe}} which has them. MB 19:47, 3 April 2022 (UTC)[reply]
That's what I thought. These are among several related templates that apparently use tables to splice together. I'd like to hold off changing any others so we can perhaps hear from other involved editors as to whether or not these templates should continue to violate MOS:SMALL, and perhaps why they do in the first place? P.I. Ellsworth - ed. put'r there 19:56, 3 April 2022 (UTC)[reply]
To editors RandomCanadian, Lithopsian, AstroMark, ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ, Nrco0e, Assambrew and Praemonitus: thought to ask for guidance. P.I. Ellsworth - ed. put'r there 20:18, 3 April 2022 (UTC)[reply]
I don't think it's going to harm the layout to remove those particular small tags, but you could remove the bold face to balance it out. Praemonitus (talk) 00:29, 4 April 2022 (UTC)[reply]
I don't know why they are like that, but I do note that the majority of them are "symbols" such as Ω for the longitude of the ascending node of an orbit, and as such are bold and less tiny than they might otherwise be. I hadn't really noticed them being small, but my browser is configured with a hard lower limit on font sizes and that was nudging them up slightly. Again, there is a project page that will get much more attention than posting directly here. Lithopsian (talk) 21:16, 3 April 2022 (UTC)[reply]
Comment - I have my browser set so I can fit as much text on the screen as I can comfortably read. I can make out normal infobox (85%) text just fine, but this smaller text is a problem. I think there would need to be a very good reason (which I can't imagine) to ignore MOS:SMALL here. MB 22:22, 3 April 2022 (UTC)[reply]

Update SIMBAD link[edit]

Change https://simbad.u-strasbg.fr/simbad/sim-id?Ident= to https://simbad.cds.unistra.fr/simbad/sim-id?Ident=; SIMBAD now uses the latter URL although the former still works. nussun (talk) 07:36, 2 May 2022 (UTC)[reply]

 Done Primefac (talk) 09:40, 3 May 2022 (UTC)[reply]

Template-protected edit request on 14 June 2022[edit]

The template has a field called metal2_fe, equivalent to metal_fe but for the second component. This is inconsistent with the naming of the other fields, for example rotational_velocity2 or age_myr2. Some articles have used metal_fe2 and no entry appears in the infobox. Some articles may well still be doing this. A field called metal_fe2 should be added, with identical output to metal2_fe. I don't think it needs to be too clever about handling edge cases where both fields are used, but only one line should appear in the infobox even if both fields have values (or maybe two since a visible indication of a mistake will get fixed?). Lithopsian (talk) 15:33, 14 June 2022 (UTC)[reply]

  • Support: I agree. This is an easy field for editors to get wrong, so it should allow for consistency. Praemonitus (talk) 15:49, 14 June 2022 (UTC)[reply]
 Done Primefac (talk) 10:20, 15 June 2022 (UTC)[reply]
@Primefac: unfortunately the 'metal_fe2' entry now shows up when it hasn't been assigned a value. For example, see the infobox for Epsilon Virginis. Praemonitus (talk) 12:39, 15 June 2022 (UTC)[reply]
 Fixed. Primefac (talk) 13:05, 15 June 2022 (UTC)[reply]

Precision of the distance fields[edit]

In the Gaia era, we are getting parallaxes sufficiently accurate that they stretch the number of significant figures used for the calculated distances in the starbox, or at least the margins of error on the distances. See TRAPPIST-1 for one case where the margin of error is barely 0.01 parsecs. There has been an attempt to hardcode the distances to values calculated from the parallax which I think was inspired by a desire to have three decimal places instead of two. Obviously this would only be applicable to the closest stars. Proxima Centauri may be the most extreme case, where the distance is currently showing as 1.30197 ± 0 pc, which isn't really giving the whole story. I'm not sure why it is getting rounded to straight zero, since I calculate the margin of error as 0.0001 pc and the margin of error on the light years is shown to four decimal places. Does it make sense to nudge the number of significant figures up by about one place in those cases where the parallax accuracy merits it? Lithopsian (talk) 14:35, 20 June 2022 (UTC)[reply]

I don't see any significant space constraints on the field, so I'd say yes. Praemonitus (talk) 16:40, 20 June 2022 (UTC)[reply]

Starbox observe for component of unknown visual apparent magnitude[edit]

Contrary to the documentation, omitting the visual magnitude in Template:starbox observe does not omit the row in the table, instead leaving a row with the parameter name. For Template:Starbox observe 2s, an example can be seen below for a binary star where the visual magnitude of one component has not been reported:

From GSC 03549-02811, minus references
Bugged output
Observation data
Epoch J2000.0      Equinox J2000.0
Constellation Draco
A
Right ascension 19h 07m 14.0376s
Declination +49° 18′ 59.091″
Apparent magnitude (V) 11.41
B
Right ascension ~19h 07m 14s
Declination ~+49° 18′ 59″
Apparent magnitude (V) {{{appmag_v2}}}
Expected result
Observation data
Epoch J2000.0      Equinox J2000.0
Constellation Draco
A
Right ascension 19h 07m 14.0376s
Declination +49° 18′ 59.091″
Apparent magnitude (V) 11.41
B
Right ascension ~19h 07m 14s
Declination ~+49° 18′ 59″

–LaundryPizza03 (dc̄) 09:22, 21 January 2023 (UTC)[reply]

This is only the case for appmag_v1 and appmag_v2 in {{Starbox observe 2s}}. It works fine for appmag_v in {{Starbox observe}}. Either omitting the appmag_v field or leaving it empty will cause the row not to display at all, as is standard for almost every field in the starbox templates. In {{starbox observe 2s}} and {{starbox observe 3s}}, leaving the appmag_v fields empty causes the row to display with no value, while omitting it completely causes the row to display as shown in the example. I'll have a go at fixing these. Lithopsian (talk) 13:51, 22 January 2023 (UTC)[reply]
I've edited both {{starbox observe 2s}} and {{starbox observe 3s}}. They should be working fine now. Shout out if you see any problems. Lithopsian (talk) 14:40, 22 January 2023 (UTC)[reply]

Exoplanet encyclopaedia (EPE) not working[edit]

The url generated for the EPE field is https://exoplanet.eu/..., but this fails. I think it is because there is no secure server for that site. The same url without https:// seems OK and gets directed to a non-secure page. Lithopsian (talk) 14:06, 23 January 2023 (UTC)[reply]

Request for additional parameters to Starbox orbit and detail[edit]

I would like to add the following:

For Starbox orbit:

For Starbox detail:

  • Spin-down period (spin period derivative commonly expressed in seconds per second; essential for neutron stars)
  • Surface magnetic field B (commonly in Gauss units, useful for stellar remnants such as white dwarfs and neutron stars)
  • Characteristic age (age since formation from supernova, used in neutron stars_

Nrco0e (talk) 05:47, 4 March 2023 (UTC)[reply]

How to make the template not overlink[edit]

As noted here, currently, the template links to colour index, color index and apparent magnitude multiple times. Is it possible to make only the first link display? I am not sure whether one can simply remove the links or if somewhat more complex markup is needed. Jo-Jo Eumerus (talk) 10:45, 3 July 2023 (UTC)[reply]

Not a trivial thing. It isn't obvious which of the various colour index and apparent magnitudes have been included for a particular star, therefore which is the "first" and which not the first. The template can work it out of course, but it gets very messy. You can't edit the template yourself, but you can play in the sandbox. Lithopsian (talk) 11:11, 3 July 2023 (UTC)[reply]
We could produce the link to Apparent magnitude if |appmag_1_passband= is defined but not for |appmag_2_passband=, |appmag_3_passband=, etc. Perhaps a similar idea for the other terms. — Martin (MSGJ · talk) 11:12, 3 July 2023 (UTC)[reply]
For the color index link I would need to know if U−B, B−V, V−R, R−I, J−H and J−K are always defined or whether it could be some subset of these? — Martin (MSGJ · talk) 11:17, 3 July 2023 (UTC)[reply]
Enforcing a rule that the passbands must be specified "in order" would make things much simpler, but the thousands of existing articles using the template may not follow that rule. No such rule is possible for the colour indices; any or all or none may be used and any combination is valid. There is overlinking in this and other templates in other cases, particularly where there are multiple components or multiple uses of the same template. Some are likely to be impossible to detect. In a few cases, fields may not be linked at all, such the the luminosity2 fields in starbox detail, although it is rare for luminosity2 to be used for component2 when luminosity is not for component1. Lithopsian (talk) 11:23, 3 July 2023 (UTC)[reply]
How about not linking any of the occurrences but wrapping the whole thing in Module:String#replace (gsub) with |count=1 to replace the first unlinked occurrence with a link. PrimeHunter (talk) 13:07, 3 July 2023 (UTC)[reply]
That sounds more practical for the original use cases at least. It might get a bit messy to extend it to ten or twenty fields getting repeated, for example in {{starbox observe 2s}} or other templates with multiple components. Regular expression pattern match on every field name? Is there a way to do that sort of global replace across multiple uses of a template within one starbox? Lithopsian (talk) 13:21, 3 July 2023 (UTC)[reply]
Sounds like a good approach to try — Martin (MSGJ · talk) 13:36, 3 July 2023 (UTC)[reply]
Any Lua coder up for creating something like Module:Link once to enforce MOS:LINKONCE by keeping track of encountered wikilinks and delink repeats? Is there already something similar I'm unaware of? PrimeHunter (talk) 13:50, 3 July 2023 (UTC)[reply]
Our resident expert on parsing wikitext is User:Aidan9382. Perhaps this is a project that might interest him? — Martin (MSGJ · talk) 09:21, 4 July 2023 (UTC)[reply]
I'd be willing to give this a look. I assume the implementation idea is to be able to wrap the entire thing in the module, something like {{#invoke:Link once|main|1=<!--Template code-->|<!--Options-->}}? Aidan9382 (talk) 16:15, 4 July 2023 (UTC)[reply]
Yes, just as simple as that. Complicated by the fact that there are multiple starbox templates that get nested between {{starbox begin}} and {{starbox end}} and each may be repeated. Here's an example article showing typical non-trivial usage. Lithopsian (talk) 16:45, 4 July 2023 (UTC)[reply]
I've drafted the module in my sandbox. You can see it in effect on the example from Sirius with and without the module wrapping it.
While it's definitely simple to enforce LO per-template, it gets much harder to do it to all templates collectively between the beginning and end templates without a change to how the templates are formatted on the article (E.g. having the entire content of the box be parameter 1 of starbox begin, making it easy to wrap it in LO) or just inserting the module itself into the article rather than the templates (like I did in my sandbox example), though perhaps im simply missing something. Aidan9382 (talk) 17:34, 4 July 2023 (UTC)[reply]
You could perhaps improve performance by only checking certain links, e.g. colour index and apparent magnitude in this case. I think the multiple links are only being produced by one template, e.g. Template:Starbox character — Martin (MSGJ · talk) 19:28, 4 July 2023 (UTC)[reply]
For backwards compatibility, I think it would need to automatically happen as part of one or other of the templates. Almost any of the starbox templates can contain multiple instances of each field, and many can be repeated. See Capella for a complex example using {{Starbox observe 3s}}, multiple components within one template, and and multiple instances of some templates such as {{starbox detail}}. We might have to just hit the more egregious overlinking offenders within single template instances? Seems a shame when this parser looks so close to catching everything all in one go. Any ideas? Lithopsian (talk) 20:07, 4 July 2023 (UTC)[reply]
Thanks a lot Aidan9382, that looks great. Omitting parameters, Capella has code of form:
{{Starbox begin}}
{{Starbox observe 3s}}
{{Starbox character}}
{{Starbox character}}
{{Starbox character}}
{{Starbox character}}
{{Starbox character}}
{{Starbox astrometry}}
{{Starbox astrometry}}
{{Starbox astrometry}}
{{Starbox astrometry}}
{{Starbox orbit}}
{{Starbox orbit}}
{{Starbox detail}}
{{Starbox detail}}
{{Starbox detail}}
{{Starbox catalog}}
{{Starbox end}}
All those templates are called directly in the source and not inside another template. The only realistic method to avoid repeated links is to wrap all the calls in something which can check for repeated links across all the template calls. There are basicallty two options, both using the new module and both requiring the article to be edited:
  1. Make a starbox wrapper template, e.g. by replacing {{Starbox begin}} and {{Starbox end}} with something like {{Starbox|1=...}}. Then the wrapper can call the module.
  2. Wrap everything directly in a new module or template like {{#invoke:Link once|main|1=...}} or {{Link once|1=...}}.
Wrapping increases the post-expand include size. Is the template limit a problem in articles where starbox templates are used? {{#invoke:Link once|main|1=...}} only passes on the wrapped text once. Using a template like {{Starbox|1=...}} or {{Link once|1=...}} would pass on the text twice, first in the template and then when it calls the module. This increases the post-expand include size further but may be more editor-friendly since many editors are unfamiliar with #invoke code. If there is consensus for a solution then we can update the documentation and request a bot to update the 5000 articles already using {{Starbox|1=...}} so I don't think lack of "backwards compatibility" is a big problem. Nothing breaks, there may just be some articles which still have repeated links if they don't use the wrapper. PrimeHunter (talk) 21:51, 4 July 2023 (UTC)[reply]
If you're entertaining updating 5k articles by bot anyway, please consider moving starbox to using {{infobox}} (e.g. with {{infobox star}} which is a convenient name, not necessarily endorsing the current implementation).
I suspect that would also resolve this issue, especially if it uses Module:infobox instead of using the infobox template. Izno (talk) 19:04, 5 July 2023 (UTC)[reply]
Out of left field, I have a question: do we really care that these starbox field titles are overlinked? They aren't in text where they would be distracting, readers may find it more convenient to have the entry they are looking at linked instead of having to go to a different one to click through. It is a fairly common practice to overlink important terms in locations such as thumbnail captions so readers who are scanning through don't have to go and find the wikilink elsewhere. Lithopsian (talk) 18:19, 6 July 2023 (UTC)[reply]
Well, the folks at WP:FAC care if we use an overlinked template on a FA candidate article. Which is why I was actually asking. Jo-Jo Eumerus (talk) 21:12, 9 July 2023 (UTC)[reply]
If that's the best suggestion for improving an article that they can come up with, I think you've got a pretty good article :) The "luminosity (bolometric)" field in Template:Starbox detail really should be linked though (its unit is linked, although it is the same unit as for "luminosity"!). There is bolometric luminosity, although it is currently a redirect to a section in luminosity, but it is potentially a separate article. It is relatively uncommon for both the "luminosity" and "luminosity (bolometric)" fields to be used since they are effectively the same thing, so where "luminosity (bolometric)" is used, it is likely that there will be no link at all to luminosity. So it should be linked to something, with only a small risk of overlinking that *might* be solved anyway by whatever else is done to kill the overlinks. Same for "luminosity (visual)", although both "luminosity (bolometric)" and "luminosity (visual)" may be used at the same time. Lithopsian (talk) 11:19, 10 July 2023 (UTC)[reply]
Bump to ask if the template still overlinks. Jo-Jo Eumerus (talk) 16:45, 10 July 2023 (UTC)[reply]
Yes. Lithopsian (talk) 18:15, 10 July 2023 (UTC)[reply]
The change(s) that need to happen are non-trivial to implement and are unlikely to happen on any timeline reasonable for a candidacy. You should respond as such at FAC. (And just to cut off the line of thought, having the links for non-technical readers outweighs any possible consideration for OLINK.) Izno (talk) 18:19, 10 July 2023 (UTC)[reply]

Broader redesign of apparent-magnitude and color-index entries[edit]

It seems like activity on #How to make the template not overlink has stagnated. The proposed stop-gap work-around at TRAPPIST-1 breaks popups.

I would propose taking a step back and looking at the wider design rather than just the over-linking. Currently there are a bunch of infobox rows that have nearly the same tag term and a parenthetical specific detail. I think it would be cleaner to follow the design of {{Infobox settlement}} and have a single pseudo-header for the tag (with link) and then subsequent rows only need the specific detail. That means there is always exactly one link (with no pre-parsing/wrapper code) and it's also simpler to read and recognize the related set of data.

TRAPPIST-1
(current implementation)
Characteristics
Evolutionary stage Main sequence
Spectral type M8V
Apparent magnitude (R) 16.466±0.065
Apparent magnitude (I) 14.024±0.115
Apparent magnitude (J) 11.354±0.022
Apparent magnitude (H) 10.718±0.021
Apparent magnitude (K) 10.296±0.023
V−R color index 2.332
R−I color index 2.442
J−H color index 0.636
J−K color index 1.058
TRAPPIST-1
(sub-grouping mockup)
Characteristics
Evolutionary stage Main sequence
Spectral type M8V
Apparent magnitude
• R 16.466±0.065
• I 14.024±0.115
• J 11.354±0.022
• H 10.718±0.021
• K 10.296±0.023
Color index
• V−R 2.332
• R−I 2.442
• J−H 0.636
• J−K 1.058

DMacks (talk) 20:52, 2 December 2023 (UTC)[reply]

That seems better in some aspects. I've notified the wikiprojects. Jo-Jo Eumerus (talk) 12:20, 5 December 2023 (UTC)[reply]
A big improvement.   ~ Tom.Reding (talk ⋅dgaf)  13:18, 5 December 2023 (UTC)[reply]
Generally I like it. Primefac (talk) 13:20, 5 December 2023 (UTC)[reply]
My concern is how it will look if the box only includes, say, the B-V value with one or zero infrared magnitudes. This redesign may result in extra clutter. Praemonitus (talk) 17:14, 7 December 2023 (UTC)[reply]
Quick mockup of sections if they were single-valued (there's a lot of superfluous wikicode that I only removed part of when copy+pasting from the original example):
TRAPPIST-1
(single-line current implementation)
Characteristics
Evolutionary stage Main sequence
Spectral type M8V
Apparent magnitude (R) 16.466±0.065
V−R color index 2.332
TRAPPIST-1
(single-line sub-grouping mockup)
Characteristics
Evolutionary stage Main sequence
Spectral type M8V
Apparent magnitude
• R 16.466±0.065
Color index
• V−R 2.332
I was thinking of suggesting to revert to the "current implementation" on the left for single-valued sections (but keeping the horizontal lines), but I'm ok with the proposed style even if it adds a little bit of extra height. Not changing back and forth between styles would add to the consistency between articles, and make values easier to find.   ~ Tom.Reding (talk ⋅dgaf)  17:58, 7 December 2023 (UTC)[reply]
I will likely not be the one to implement it if we decide to go with it, but I feel like having two systems will just be more complicated (and lead to a lot more debug issues if/when things need updating). I will note that there are a ton of templates (mainly government- or settlement-related) that have this sort of "header-plus-bulleted-entry" style with the offset value, so it's not like it will be unique in its layout. Primefac (talk) 19:03, 7 December 2023 (UTC)[reply]
The vast majority of stars are not going to need that amount of clutter. Note that you could always resort to having two templates: one for detail (e.g. Proxima Centauri) and for not (e.g. Epsilon Tauri). Praemonitus (talk) 22:38, 7 December 2023 (UTC)[reply]
@DMacks, Tom.Reding, Praemonitus, and Primefac: So, where are we here? Leave unchanged, go to the new version with sub-grouping always, or sub-grouping only with multiple lines? Jo-Jo Eumerus (talk) 08:24, 17 December 2023 (UTC)[reply]
I strongly oppose leaving it unchanged, since it creates a problem, and the alternatives solve the problem (without creating any problem as user- or editor-visible:). Among the alternatives, I agree with Tom.Reding's preference for consistency, rather than different layouts and entry-titles depending how many entries there are. I don't see the need for two different templates even if we did have two different modes: it would be easy to have the single template conditionalize itself on the presence of more than one sub-entry of a type. Obviously reducing code duplication is good, and having fewer options is simpler and less error-prone. For Praemonitus's concern, the dividing line and internal header for the set would be omitted altogether if there are no entries (just like infoboxes usually omit entries that have no values). DMacks (talk) 08:55, 17 December 2023 (UTC)[reply]
I can get behind the new layout. I don't think the "we can't have a single entry like this" complaint has merit, but I'm not going to fight to have a single template layout even if it means a lack of ease of updating. Primefac (talk) 13:10, 17 December 2023 (UTC)[reply]
We already use the multiple template approach depending on the number of components, so I see no reason not to do the same in this case. I'd argue that most of the magnitude information is of little interest to the vast majority of readers anyway, and this discussion is concerning only a minority of the articles. There's no reason to introduce additional clutter just for data that usually isn't presented and most people don't read or appreciate. Praemonitus (talk) 14:03, 17 December 2023 (UTC)[reply]
Meh, I would probably punt the "sub-grouping always" and "sub-grouping only when multiple lines" to a parameter. Or is it possible to have the template count the number of parameters it has received. Jo-Jo Eumerus (talk) 14:50, 17 December 2023 (UTC)[reply]
If there's no agreement, I like the grouping-parameter idea over forcing whichever one, at least from a user's perspective, and not from an implementation/TE's perspective.   ~ Tom.Reding (talk ⋅dgaf)  14:59, 17 December 2023 (UTC)[reply]
Yes, that's a good suggestion. It raises the question: if we use such a parameter, can it be set to a default value based on the input value of other parameters? Praemonitus (talk) 16:24, 17 December 2023 (UTC)[reply]
{{#invoke:ParameterCount|main|...}} counts the number of parameters matching a lua pattern. DMacks (talk) 18:17, 17 December 2023 (UTC)[reply]
'fraid that I don't know how to write up such a template. Jo-Jo Eumerus (talk) 07:25, 23 December 2023 (UTC)[reply]
I will volunteer to work on it, but astronomy is not my field so I would first like to see either consensus for the desired results or consensus that it doesn't really matter much/instead up to the template-author. DMacks (talk) 12:03, 23 December 2023 (UTC)[reply]
I think we can start with a counter version i.e "sub-grouping" when more than one non-empty parameter and "one line" when only one. Jo-Jo Eumerus (talk) 07:32, 27 December 2023 (UTC)[reply]

Poll[edit]

@DMacks, Tom.Reding, Praemonitus, and Primefac:So that this doesn't get abandoned: Do folks prefer a template with always sub-grouping, two templates one with sub-grouping and one without, or a template with a parameter that tells whether to subgroup, or something else? Jo-Jo Eumerus (talk) 07:17, 9 January 2024 (UTC)[reply]

  • First choice to always sub-group, second choice switch based on count, hard no to the parameter option because then we'll just end up arguing at every page which flavour of output should be used. Primefac (talk) 07:26, 9 January 2024 (UTC)[reply]
  • First choice to always sub-group, second choice switch based on count.   ~ Tom.Reding (talk ⋅dgaf)  12:42, 9 January 2024 (UTC)[reply]

Notification: exoplanet.eu dead[edit]

The template contains the line:

{{#if:{{{EPE<includeonly>|</includeonly>}}}|<tr><td>'''[[Extrasolar Planets Encyclopaedia|Extrasolar Planets<br />Encyclopaedia]]'''</td><td>[http://exoplanet.eu/star.php?st={{{EPE}}} data]

The exoplanet.eu site no longer supports direct links to star systems, and doesn't have unique pages for star systems. The only way to get this link working is to make a default archive.org link, but this is not recommended as the data will be outdated. Recommend removing exoplanets.eu from this template, the site is for planets afterall. -- GreenC 02:41, 23 December 2023 (UTC)[reply]

Support: yes, that has been dead and irrelevant for a while now. Praemonitus (talk) 05:38, 23 December 2023 (UTC)[reply]
If it doesn't work anymore and can't be repaired, it should be removed. Jo-Jo Eumerus (talk) 07:24, 23 December 2023 (UTC)[reply]
 Done. Primefac (talk) 07:28, 9 January 2024 (UTC)[reply]

Starbox relpos title isn't centered[edit]

Example
Position (relative to HD 107148 A)
ComponentHD 107148 B
Epoch of observation2009
Angular distance34.9″
Position angle174.7°
Projected separation1,790 AU

For reasons I can't discern, the title row of the {{Starbox relpos}} template isn't being centered. I also think "Angular distance" should be linked and the "Observed separation (projected)" label should be simplified to "Projected separation". Praemonitus (talk) 18:29, 8 January 2024 (UTC)[reply]

Should be sorted now, I think the main issue was the code being written wrong, but trying to shove everything onto one line probably didn't help either. Primefac (talk) 07:37, 9 January 2024 (UTC)[reply]
Thank you. Praemonitus (talk) 14:10, 9 January 2024 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Starbox_begin&oldid=1194540637"