Template talk:Starbox begin#Template-protected edit request on 3 April 2022

:{{done}}. {{to|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 {{tl|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)

::{{u|Paine Ellsworth}}, actually, I got here from {{tl|Starbox observe}} which has them. MB 19:47, 3 April 2022 (UTC)

:::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)

:::{{to|RandomCanadian|Lithopsian|AstroMark|ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ|Nrco0e|Assambrew|Praemonitus}} thought to ask for guidance. P.I. Ellsworth - ed. ^put'r there 20:18, 3 April 2022 (UTC)

:::: 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)

• The other templates which still use this (seems to be mostly for unit symbols) are :Template:Starbox detail; :Template:Starbox orbit (not template-protected); :Template:Starbox character; :Template:Starbox observe 3s and :Template:Starbox observe 2s (not template-protected); and as noted :Template:Starbox observe. There's definitively no good reason why these should be smaller than regular infobox font size. RandomCanadian (talk / contribs) 20:30, 3 April 2022 (UTC)
• (latest edit request as of 0300 UTC / 03.04) I have gone ahead and removed the tags from the pages which are not protected, given the general consensus for it here. Please remove it from the other ones too (listed right here above). Cheers, RandomCanadian (talk / contribs) 03:00, 4 April 2022 (UTC)
• {{done}}. P.I. Ellsworth - ed. ^put'r there 19:34, 4 April 2022 (UTC)

: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)

::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)

• I too would support removing small tags from the templates involved per MOS:SMALLFONT. Not that it makes a difference to mobile readers where small tags do not render anyways. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 02:47, 4 April 2022 (UTC)

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)

:{{done}} Primefac (talk) 09:40, 3 May 2022 (UTC)

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)

• 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)

:{{done}} Primefac (talk) 10:20, 15 June 2022 (UTC)

::{{ping|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)

:::{{fixed}}. Primefac (talk) 13:05, 15 June 2022 (UTC)

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

{{collapse top|From GSC 03549-02811, minus references}}

{{starbox begin|name=Bugged output}}

|- "text-align: center;"

! style="text-align: center; background-color: #FFFFC0;" colspan="2" | Observation data
{{#ifeq:J2000.0|J2000.0 (ICRS)|Epoch J2000.0      Equinox J2000.0 (ICRS)| Epoch J2000.0      Equinox J2000.0}}

|-

| Constellation

| Draco

|- style="vertical-align:top"

{{#if:|

! style="text-align:left" {{!}} Pronunciation

{{!}} {{{pronounce}}}

}}

|-

| colspan="2" style="text-align: center" | A

|-

| {{nowrap|Right ascension}}

| {{RA|19|07|14.0376}}

|-

| {{nowrap|Declination}}

| {{DEC|+49|18|59.091}}

|-

| {{nowrap|Apparent magnitude (V)}}

| 11.41

|-

| colspan="2" style="text-align: center" | B

|-

| {{nowrap|Right ascension}}

| ~{{RA|19|07|14}}

|-

| {{nowrap|Declination}}

| ~{{DEC|+49|18|59}}

|-

| {{nowrap|Apparent magnitude (V)}}

| {{{appmag_v2}}}

{{starbox end}}

{{starbox begin|name=Expected result}}

|- "text-align: center;"

! style="text-align: center; background-color: #FFFFC0;" colspan="2" | Observation data
{{#ifeq:J2000.0|J2000.0 (ICRS)|Epoch J2000.0      Equinox J2000.0 (ICRS)| Epoch J2000.0      Equinox J2000.0}}

|-

| Constellation

| Draco

|- style="vertical-align:top"

{{#if:|

! style="text-align:left" {{!}} Pronunciation

{{!}} {{{pronounce}}}

}}

|-

| colspan="2" style="text-align: center" | A

|-

| {{nowrap|Right ascension}}

| {{RA|19|07|14.0376}}

|-

| {{nowrap|Declination}}

| {{DEC|+49|18|59.091}}

|-

| {{nowrap|Apparent magnitude (V)}}

| 11.41

|-

| colspan="2" style="text-align: center" | B

|-

| {{nowrap|Right ascension}}

| ~{{RA|19|07|14}}

|-

| {{nowrap|Declination}}

| ~{{DEC|+49|18|59}}

{{starbox end}}

{{collapse bottom}} –LaundryPizza03 (dc̄) 09:22, 21 January 2023 (UTC)

:This is only the case for appmag_v1 and appmag_v2 in {{t|Starbox observe 2s}}. It works fine for appmag_v in {{t|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 {{t|starbox observe 2s}} and {{t|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)

::I've edited both {{t|starbox observe 2s}} and {{t|starbox observe 3s}}. They should be working fine now. Shout out if you see any problems. Lithopsian (talk) 14:40, 22 January 2023 (UTC)

For Starbox orbit:

• Epoch (not periastron epoch)
• Longitude of perihelion ϖ (I see that researchers don't really use arg of periastron and ascending node separate like in [https://iopscience.iop.org/article/10.3847/2041-8213/aaad06/pdf PSR J1946+2052])
• Rate of periastron advance $\backslash dot\; \backslash bar\; \backslash omega$ (apsidal precession, significant for binary neutron stars)

For Starbox detail:

• Spin-down period $\backslash dot\; P$ (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)

: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)

:We could produce the link to Apparent magnitude if {{para|appmag_1_passband}} is defined but not for {{para|appmag_2_passband}}, {{para|appmag_3_passband}}, etc. Perhaps a similar idea for the other terms. — Martin (MSGJ · talk) 11:12, 3 July 2023 (UTC)

::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)

::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)

:::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)

::::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 {{t|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)

::::Sounds like a good approach to try — Martin (MSGJ · talk) 13:36, 3 July 2023 (UTC)

:::::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)

::::::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)

:::::::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=|}}? Aidan9382 _(talk) 16:15, 4 July 2023 (UTC)

::::::::Yes, just as simple as that. Complicated by the fact that there are multiple starbox templates that get nested between {{t|starbox begin}} and {{t|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)

:::::::::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)

::::::::::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)

:::::::::::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 {{t|Starbox observe 3s}}, multiple components within one template, and and multiple instances of some templates such as {{t|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)

: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 {{tl|Starbox begin}} and {{tl|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)

::If you're entertaining updating 5k articles by bot {{em|anyway}}, please consider moving starbox to using {{tl|infobox}} (e.g. with {{tl|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)

: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)

::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)

:::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)

:Bump to ask if the template still overlinks. Jo-Jo Eumerus (talk) 16:45, 10 July 2023 (UTC)

::Yes. Lithopsian (talk) 18:15, 10 July 2023 (UTC)

::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)

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 {{tl|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.

:That seems better in some aspects. I've notified the wikiprojects. Jo-Jo Eumerus (talk) 12:20, 5 December 2023 (UTC)

:A big improvement.   ~ Tom.Reding (talk ⋅dgaf)  13:18, 5 December 2023 (UTC)

::Generally I like it. Primefac (talk) 13:20, 5 December 2023 (UTC)

: 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)

:: 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):

::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)

::: 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)

::: 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)

:::{{ping|DMacks|Tom.Reding|Praemonitus|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)

::::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)

:::::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)

:::::: 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)

:::::::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)

::::::::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)

:::::::: 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)

::::::::{{ml|ParameterCount|main|...}} counts the number of parameters matching a lua pattern. DMacks (talk) 18:17, 17 December 2023 (UTC)

:::::::::'fraid that I don't know how to write up such a template. Jo-Jo Eumerus (talk) 07:25, 23 December 2023 (UTC)

::::::::::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)

:::::::::::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)

• 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)
• First choice to always sub-group, second choice switch based on count.   ~ Tom.Reding (talk ⋅dgaf)  12:42, 9 January 2024 (UTC)

:{{#if:{{{EPE|}}}|Extrasolar Planets
Encyclopaedia[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)

: Support: yes, that has been dead and irrelevant for a while now. Praemonitus (talk) 05:38, 23 December 2023 (UTC)

: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)

::{{done}}. Primefac (talk) 07:28, 9 January 2024 (UTC)

{{Starbox relpos

| reference =

| epoch = 2009

| primary = HD 107148 A

| component = HD 107148 B

| angdistsec = 34.9

| posang = 174.7

| projsep = 1,790

}}

{{Starbox end}}

For reasons I can't discern, the title row of the {{tl|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)

: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)

:: Thank you. Praemonitus (talk) 14:10, 9 January 2024 (UTC)

The NASA Exoplanet Archive link should be updated to https://exoplanetarchive.ipac.caltech.edu/overview/{{{NSTED}}}, the old https://exoplanetarchive.ipac.caltech.edu/cgi-bin/DisplayOverview/nph-DisplayOverview?objname={{{NSTED}}} currently still lands though Slovborg (talk) 20:59, 17 November 2024 (UTC)

:Is it just for {{param|NSTED}} or do the links for {{param|NSTED2}} and {{param|NSTED3}} also need fixing? Primefac (talk) 14:11, 18 November 2024 (UTC)

::Oh yeah – all the links should be adjusted to fit the new site structure. Slovborg (talk) 17:26, 19 November 2024 (UTC)

:::Should be sorted now. Primefac (talk) 12:15, 22 November 2024 (UTC)

::::Seems to be working. Thanks! Slovborg (talk) 11:49, 23 November 2024 (UTC)

• Support: it could be linked to Scientific notation, but the term seems to be primarily used in astronomy so the metallicity link makes sense. I added a reference to the defining sentence. Praemonitus (talk) 17:09, 21 January 2025 (UTC)

I have modified the sandbox to prevent wrapping of unit fields containing a slash character: "km/s" and "mas/yr", using {{t|nowrap}} to include the preceding space (previously  ) and the whole unit. I have tested the results to see that they prevent the wrapping shown at R Canis Majoris, HD 187474, and HD 174881, and that nothing terrible happens on major pages including Sirius and Alpha Centauri. Can you apply this to the main template? Lithopsian (talk) 18:26, 20 February 2025 (UTC)

:@Lithopsian Template:Starbox begin/sandbox has no edits from you? Sohom (talk) 00:04, 24 February 2025 (UTC)

::Ah, much confusion. I edited Template:Starbox astrometry/sandbox for {{t|Starbox astrometry}}. I got redirected to this talk page so my edit request shows as being for this page, and I didn't notice. Lithopsian (talk)

::: {{done}} * Pppery * _{it has begun...} 21:57, 24 February 2025 (UTC)

:Thanks. The starboxes are much tidier now. Lithopsian (talk) 17:23, 25 February 2025 (UTC)

{{edit template-protected|Template:Starbox catalog|answered=yes}}

I have edited the sandbox to drop the hard wrapping at 250px. The designation list will now wrap naturally either at the width required by other sections of the starbox or at the width of the longest unbroken string of characters in the designation list. This has been discussed at Wikipedia talk:WikiProject Astronomical objects#Starbox catalog wrapping with no objection. Lithopsian (talk) 20:25, 9 March 2025 (UTC)

:{{done}} Primefac (talk) 13:10, 11 March 2025 (UTC)

So, should luminosity be linked to bolometric luminosity (or directly to the section Luminosity#Measurement instead of just Luminosity) since it almost never contains anything other than a bolometric luminosity? The Measurement section starts helpfully with the words "When not qualified, the term "luminosity" means bolometric luminosity". Should luminosity_visual be linked? And where? The field luminosity_bolometric2 is linked to the same target as luminosity_bolometric. I'm assuming that luminosity2 should be linked to the same target as luminosity.Lithopsian (talk) 16:34, 15 April 2025 (UTC)

: Perhaps they should all be linked to a redirect from Luminosity measurement to an anchor at Luminosity#Measurement, since that section also covers the passband cases? Praemonitus (talk) 15:22, 27 April 2025 (UTC)

::I've created the redirect so it is there if we want to use it. Lithopsian (talk) 16:27, 27 April 2025 (UTC)

Please add nowrap clauses around the " mas/yr" units for prop_mo_ra2 and prop_mo_dec2, the same as already in place for prop_mo_ra and prop_mo_dec. These units can otherwise wrap at the "/" character. which can be confusing and disconcerting. I'll offer HD 142 as an example where this happens (for me), but it may depend on your theme and other aspects of your setup such as available fonts and DPI. Lithopsian (talk) 14:10, 6 May 2025 (UTC)

:{{complete2}}. P.I. Ellsworth , ed. ^{put'er there} 18:54, 6 May 2025 (UTC)

In {{t|Starbox detail}}, the metallicity units "[Fe/H]" can wrap at the slash, which is unfortunate. Other units where this could happen contain no-break-spaces. In the sandbox, I have tested no-wrapping this unit. The field caption "Metallicity [Fe/H]" may still wrap at the space. Please promote this version to the live template. Lithopsian (talk) 19:48, 15 May 2025 (UTC)

: {{done}} * Pppery * _{it has begun...} 03:26, 16 May 2025 (UTC)

Description of suggested change:

Please update {{t|Starbox astrometry}} from the sandbox.

There are some inconsistencies (or errors) between the behaviour of the first (component1) set of fields and the second (component2) set:

• The first parallax margin of error (p_error) is formatted using {{t|±}} and the second (p_error2) using " ± ", which is likely to render with a slightly different spacing and will be different if copied.
• When there is no margin of error field (p_error) then no distance is calculated from the first parallax, but one is shown—usually with an insane number of decimal places—if there is a parallax2 field without a p_error2 field.
• When only one of prop_mo_ra and prop_mo_dec is specified, the other is shown empty (with a mas/yr unit), but when only one of prop_mo_ra2 and prop_mo_dec2 is specified, the other is shown with a hyphen ("- mas/yr"), which is inconsistent and could potentially be confused with a minus sign.

I have edited and tested the sandbox to make the second set of fields behave like the first set for these three cases. Lithopsian (talk) 16:10, 3 June 2025 (UTC)

I have edited the template sandbox to correctly encode spaces (and potentially other characters) for use in the url, which allows articles to use NSTED fields without having to encode spaces. However, most articles do not currently use a space because it produces visibly broken output in the starbox. Most articles use "+". Should I code the template to replace "+" with "%20" and have most current uses work, but break future uses of designators containing "+"? Or is there some relatively painless way to change all the current uses of the template that have "+" in an NSTED field? Or even just to find them all, I suspect no more than a few hundred. Lithopsian (talk) 14:16, 8 June 2025 (UTC)

:I now have a hopefully-complete list of all articles that use "+" to replace a space character in an NSTED field. Less than 200, which isn't as bad as I feared. These are all broken now, and they'll all be broken if the current sandbox template is adopted. A small number of articles use "+" as an actual part of the designation (eg. WD 1856+534); these should all work now and should continue to work if the field is encoded, but any hacks to make the template treat "+" as being a substitute for a space would break them.

:There are several workarounds for space characters, which are used in many articles. In many cases, the website will accept "_" or "-" as a replacement character, and often no space at all will work. This should all be fine, even if those fields are then url-encoded. A few articles were already using "%20" to substitute for a space; I have edited all of these because url-encoding them would break the url. Lithopsian (talk) 15:39, 9 June 2025 (UTC)

:So, all "+" characters representing spaces are now gone and the NSTED links should all work now (although some may not exist). It is unfortunate that the handling of spaces is inconsistent between the Simbad and NSTED fields, but that is inevitable given the URL formats involved. If anything, the Simbad fields should be changed to properly url-encode the field per whatever URL is current, but that would involved changing thousands of articles instead of just 100 and some. Lithopsian (talk) 17:52, 10 June 2025 (UTC)

Description of suggested change:

Please promote {{t|Starbox reference/sandbox}} to {{t|Starbox reference}}. Currently, a space in an NSTED field breaks everything, and the traditional solution of explicitly putting a "+" in the field instead of spaces doesn't work with the new url format. I have edited the NSTED fields so that they are correctly urlencoded, usually replacing a space with "%20" so that a valid url is formed. This enables star designations containing a space, and potentially other invalid url path characters, to be used in the starbox for NASA Exoplanet Archive references.

Note that uses of the template which already contain a "+" character intended to replace a space will continue to be broken after this change. See the discussion above for details. It is not yet clear whether these will be fixed by editing the articles or by some hack in the template. Lithopsian (talk) 13:48, 9 June 2025 (UTC)

:{{re|Lithopsian}} {{done}}. We could fix the broken articles by adding {{tlx|replace}} to the template (something like {{tlx|replace|string|+|%20}} in this case), but I think it would be better to directly update the articles (possibly via AWB). In case you also discussed this topic elsewhere, let me know if you managed to gather better tips, and if you still have that {{tq|list of all articles that use "+" to replace a space character in an NSTED field}}, please share it as well. Thanks. Est. 2021 (talk · contribs) 02:08, 10 June 2025 (UTC)

::Here's the list of articles I found. I believe they have all been edited to correctly produce a link to a NASA Exoplanet Archive page. Quite a number don't appear to exist (any more?) and so I have commented out the NSTED field.

{{collapse|

• 11 Ursae Minoris
• 18 Scorpii
• 23 Librae
• 2MASS J0249-0557
• 2MASS J0249-0557
• 30 Arietis
• 36 Ophiuchi
• 47 Ursae Majoris
• 6 Lyncis
• 70 Virginis
• 85 Pegasi
• 89 Herculis
• BD%E2%88%9210%C2%B03166
• BD%E2%88%9217 63
• Chi Virginis
• Delorme 1
• DP Leonis
• Gamma Cephei
• Gamma Leonis
• GJ 1214
• GJ 3634
• Gliese 179
• Gliese 22
• Gliese 317
• Gliese 570
• Gliese 676
• Gliese 86
• Gliese 900
• Gliese 900
• HD 101581
• HD 103197
• HD 103774
• HD 104067
• HD 106252
• HD 106515
• HD 108874
• HD 109271
• HD 110067
• HD 114762
• HD 114783
• HD 11506
• HD 118203
• HD 11964
• HD 121504
• HD 125595
• HD 125612
• HD 129445
• HD 131664
• HD 13931
• HD 139357
• HD 145377
• HD 1461
• HD 147018
• HD 148156
• HD 148427
• HD 152079
• HD 156668
• HD 158259
• HD 158259
• HD 162020
• HD 166724
• HD 16760
• HD 168746
• HD 1690
• HD 171238
• HD 175167
• HD 176051
• HD 179079
• HD 181433
• HD 183263
• HD 185269
• HD 189733
• HD 190984
• HD 191806
• HD 191939
• HD 20003
• HD 201585
• HD 202628
• HD 203030
• HD 203473
• HD 20367
• HD 204313
• HD 208527
• HD 215497
• HD 219077
• HD 220074
• HD 220689
• HD 221420
• HD 240210
• HD 2638
• HD 27631
• HD 28254
• HD 290327
• HD 29587
• HD 30562
• HD 34445
• HD 35759
• HD 36384
• HD 37605
• HD 38858
• HD 40307
• HD 4113
• HD 4203
• HD 42936
• HD 43197
• HD 43848
• HD 44219
• HD 45184
• HD 45364
• HD 47186
• HD 48265
• HD 5319
• HD 5388
• HD 60532
• HD 66141
• HD 6718
• HD 68402
• HD 69830
• HD 70642
• HD 7199
• HD 73267
• HD 73344
• HD 76700
• HD 7924
• HD 8535
• HD 85390
• HD 86081
• HD 86226
• HD 86264
• HD 87883
• HD 89744
• HD 90156
• HD 92788
• HD 9446
• HD 9578
• HD 96167
• HD 98649
• HIP 14810
• HIP 5158
• HIP 56948
• HIP 70849
• HR 8799
• HR 8799
• Mu2 Octantis
• Omicron Coronae Borealis
• QS Virginis
• Rho Indi
• RR Caeli
• SR 12 (star)
• V429 Geminorum
• VB 10
• Xi2 Ceti

}} Lithopsian (talk) 17:48, 10 June 2025 (UTC)