Wikipedia talk:WikiProject Elements

I'm i the process of removing undiscovered decay modes from isotope lists I've edited, unless there is an experimental bound. But I'm not sure how to denote decay modes with unknown branching ratio, such as the β⁺ and β⁺p modes of ¹²⁴Pr:

• β⁺
• β⁺?
• β⁺ (?%)
• β⁺ (unknown%)
• Add a new column with the branching ratio.

–LaundryPizza03 (dc̄) 11:58, 30 September 2024 (UTC)Reply

β⁺ (?%) is succinct & unambiguous. YBG (talk) 09:31, 1 October 2024 (UTC)Reply

+1 Double sharp (talk) 09:59, 1 October 2024 (UTC)Reply

I agree with YBG and Double sharp. Any potential confusion (e.g., unobserved decay modes vs. observed decay modes with unknown branching radio) can be resolved with explanatory footnotes. ^Complex/_Rational 11:53, 1 October 2024 (UTC)Reply

Like main isotopes, main oxidation state is also something that varies in different Wikipedia articles. Some oxidation states like Tl(+3) and Co(+3) are either bolded or not in different languages of Wikipedia. There might be a need for a criteria of main oxidation states. Nucleus hydro elemon (talk) 10:10, 3 October 2024 (UTC)Reply

I think it may have started with "does Greenwood and Earnshaw consider it a 'more common oxidation state' in their table on p.28". Double sharp (talk) 13:10, 3 October 2024 (UTC)Reply

That table is a good starting point. However, there are no oxidation states listed for He, Ne, Ar, Rn, and Db and beyond, so other sources are needed for them. No is also a problem, as the article says No(+2) is more stable than No(+3), but it is reversed in Greenwood and Earnshaw. Nucleus hydro elemon (talk) 14:07, 3 October 2024 (UTC)Reply

We need to resolve this issue of defining "main". I'm fine with "what Greenwood and Earnshaw call common" as long as we can stick with it. The other definition I've seen is "stable", as in an oxidation state that would be stable as ion (aqueous? IDK). There also the historical concept of states corresponding to naturally occurring oxides which I think is nicely educational. However these other directions require sources/discussions.

So let me make a concrete proposal: the "main" oxidation states are those listed Greenwood and Earnshaw as "more common". One upshot is the these oxidation states would all be source to one place.

This will fail for some transuranium elements I guess, see

• Fricke, B. (2007). Superheavy elements a prediction of their chemical and physical properties. In Recent impact of physics on inorganic chemistry (pp. 89-144). Berlin, Heidelberg: Springer Berlin Heidelberg.

which talks about predicted "stable" oxidation states. Johnjbarton (talk) 00:29, 6 October 2024 (UTC)Reply

I like the idea of standardizing and G&E seems a good choice. If we go with G&E data, I suggest we also follow G&E nomenclature, specifically, ie, say "more common" instead of "main". And maybe that nomenclature might be a justification for not bolding the trans uranium ones. YBG (talk) 02:54, 6 October 2024 (UTC)Reply

Does anyone have a CRC? If it has similar data, then I would lean to use it out of ubiquity. Johnjbarton (talk) 03:04, 6 October 2024 (UTC)Reply

By the way, there is a dispute about necessariness of listing every oxidation state. I think it deserves to be discussed here. Nucleus hydro elemon (talk) 14:10, 3 October 2024 (UTC)Reply

Thank you. That was my post, and my point was especially pointed at infobars.

In my opinion as a chemist and editor, the thing you describe as "main oxidation state" is a chemically significant characteristic of the element. This information is invaluable in rapid qualitative thinking about likely chemical compounds. When attached to an element, "main oxidation state" means "the element's predominate or common oxidation state".

Exotic oxidation states are quite a different matter. They only apply to, well, exotic compounds and thus have little predictive power. That is why they appear in the "news": when a chemist succeeds in creating an exotic compound that defies prediction they may claim the element is in a new "oxidation state". This state is not a characteristic of the element.

In terms of the element articles I think the exotic oxidation state content would be much more fun and effective if it were moved in sections entitled something like "Exotic compounds". There we would discuss things like XeF₆ which were unexpected, difficult to create, and have unusual properties. Infobars are poor location for this info because they don't allow discussion of interesting aspects of these exotica. The effect of having both "main" and "exotic" oxidation states is to dilute the value of both bits of information. Johnjbarton (talk) 15:37, 3 October 2024 (UTC)Reply

I think it's fine to put Xe as having 2, 4, 6, and 8, because a line that would bar XeF₆ and friends would bar us from putting down anything at all for that element. I do think some cutting makes sense, but what exactly would it entail? Ir(VI) has basically one exemplar (hexafluoride + maybe some derivatives), but it doesn't need exotic conditions the way VII and higher do. What about negatives in carbonyls, which have little to do with the actual charge on the central atom? And how would you source the particular line drawn in the sand? Double sharp (talk) 02:24, 4 October 2024 (UTC)Reply

Yes, this is my point. Noble gases got that name for a reason! That is why no compound of noble gases was created until 1962. The history of chemistry stretches back a thousand years and chemical synthesis has been going full bore for hundreds of years. As a natural element, the only oxidation state that matters for Xe is zero.

I agree that my proposal requires a source and it may be that the line might be unclear. Oxidation state is not an atomic property. Strictly for "Elements" all oxidation states are zero.

But it seems like this problem already exists. The Elements pages have three kinds of information under oxidation state. Two kinds of numbers, bold and normal, and some text (which links base and acid weirdly) and occasionally a ref. Somehow readers are supposed to decode this? That is what lead me to complain in the first place.

For example Rubidium has −1, +1 (a strongly basic oxide) and Iron has −4, −2, −1, 0, +1, +2, +3, +4, +5, +6, +7 (an amphoteric oxide).

What is the meaning of Rubidium's oxidation state being a strongly basic oxide? Why was +1 bold?

(maybe if you agree that there is a problem we need to think of smaller steps of improvement). Johnjbarton (talk) 02:59, 4 October 2024 (UTC)Reply

The bold means that Rb +1 is a major state, and the lack of bold means that Rb −1 isn't. The "strongly basic oxide" refers to Rb(I) oxide i.e. Rb₂O being strongly basic. I do agree this is less clear for Fe, where I would say FeO is better called basic than amphoteric, and it's not clear which oxidation state the text is describing. Maybe the parenthesis should be put next to the oxidation state it's relevant to.

Probably it would be good to state explicitly that bold oxidation states mean the main ones. Though understandings may differ: I would call Mn(VII) an important oxidation state, but it's too oxidising to find in minerals. This is likely similar to why we seem to disagree for Xe(VI): to me, talking about Xe chemistry in any way already presupposes that we are narrowing the scope to what happens when you force it into compounds, because saying "it doesn't do anything" (as writing only 0 as a main oxidation state would imply) seems a bit too boring to be the plausible meaning in context. Double sharp (talk) 03:42, 4 October 2024 (UTC)Reply

Perhaps splitting the acidic/basic properties to another row? After that, every oxide in main oxidation state can be clarified like this:

Cr₂O₃: an amphoteric oxide
CrO₃: an acidic oxide

Nucleus hydro elemon (talk) 10:28, 4 October 2024 (UTC)Reply

Splitting into another row would be good, but I don't understand the context/purpose of these phrases. Why would we list these two oxides in the infobar for Cr? Johnjbarton (talk) 18:25, 4 October 2024 (UTC)Reply

I wonder if these "comments" (such as "an acidic oxide") as they are called in the template source were intended originally to be attached to particular oxidation states, like Nucleus hydro elemon did in the box above. In the current version these comments are always at the end. Johnjbarton (talk) 18:46, 4 October 2024 (UTC)Reply

Double sharp: I want to be clear that my main point is about the infobar. The issues you raise can all be dealt with in the text. The infobar however has nothing to show readers that "bold means Rb +1 is a major state" or that '"strongly basic oxide" refers to Rb(I) oxide'. All we see in the info bar is a series of numbers and a cryptic phrase seemingly singling out some factoid about something that also has "oxi" in the word, but why?

Also note that the infobar link next to the coded message is to Oxidation state which does not explain bold, "Rb", "strongly basic oxide", or "Rb(I) oxide". Sure the editors who wrote the coded message understand it, but is that our purpose? (For a start maybe we should link the infobar line to Rubidium#Oxidation state and have it link Oxidation state). Johnjbarton (talk) 15:58, 4 October 2024 (UTC)Reply

Well, it seemed fairly obvious to me what it meant in 2008, before I'd started editing. (This convention was already around then, but due to changes in how the templates now work, you'll have to view the source to see it.) Sample size n=1, I know, but the idea that bold represents something more important than normal is fairly widespread.

I suppose we could add a note saying "main = bold", remove the characterisations of oxides (a little too much for the infobox perhaps when there are several), and then everything else can stay as it is while already being transparent. Double sharp (talk) 16:41, 4 October 2024 (UTC)Reply

A specific proposal:

Change the infobox template to

1. place the "main" oxidation states on the first line, still bold, prefixed with "Main:"
2. place the others on the second line, no annotation.
3. drop the comments (eg "an acidic oxide") or repurpose them (eg for Xe the 'others' could have a comment "rare").
4. review the outliers, eg carbon, the transuranium elements with no experimental data?

I can try to do this in a sandbox for further feedback.

This addresses my main complain about the cryptic information and mixing of highly predictive main oxidation states with the newsy other ones, but is a relatively small change. WDYT? Johnjbarton (talk) 18:57, 4 October 2024 (UTC)Reply

Looks fine for me. The last thing is sourcing to prove the exotic oxidation states do exist. Nucleus hydro elemon (talk) 01:44, 5 October 2024 (UTC)Reply

It also looks fine for me. Double sharp (talk) 04:11, 5 October 2024 (UTC)Reply

Great, thanks for the feedback. I will have some technical strategy question eventually, but first some more questions about style/editing.

We evidently have two templates that embed oxidation state data and references.

1. The infobox one Template:Infobox element/symbol-to-oxidation-state. Refs follow state numbers.
2. The List on Template:List_of_oxidation_states_of_the_elements. Refs together at the end.

The way the refs are related to the state numbers could be different on purpose (according to the lay out desired) or accidental. In the latter case, one or the other could be preferred, or may either layout would be find for both cases.

I think we could build both resources from one data set by separating the data table aspect from the formatting aspect. One template would be data table and others would call it. Before I evaluate the difficulty of this goal, I'd like to hear opinions about the ref layout question. Johnjbarton (talk) 18:31, 5 October 2024 (UTC)Reply

I fully support having a single WP data source. YBG (talk) 02:56, 6 October 2024 (UTC)Reply

I just realized some problems: The list of oxidation states explicitly state that 0 oxidation state in free element form is excluded, which make noble gases problematic. Moreover, Greenwood&Earnshaw does not list 0 oxidation state in their table, so some potential main oxidation states like Pd(0) are missed. Nucleus hydro elemon (talk) 06:50, 6 October 2024 (UTC)Reply

(Just to clarify the list says "The column for oxidation state 0 only shows elements known to exist in oxidation state 0 in compounds.")

I think a documented 0 oxidation state in a compound would be an exotic state, not a "main" or "common" one. That is, even if the value is 0, the "state of ending up in 0" is notable if sources back that up. So I will claim this is another advantage of separating the common and exotic states.

For common state we can either list 0 with every element or exclude it. For noble gases we could have "(none)". I kinda like that idea. Johnjbarton (talk) 14:49, 6 October 2024 (UTC)Reply

I now kind of wonder why Pd(0) is bolded in oxidation state. Isn't this mostly about phosphine complexes and relatives? If so, then we start getting into the question about whether carbonyls and other such compounds are familiar enough to justify things like Cr(0) and Fe(0).

If 0 is to be listed for every element as a common state, then it must be referring to the simple substance, and then 0 must be common for noble gases. If it is not listed, then we are confining ourselves to only compounds, and then it makes some sense to put (none) for noble gases. The former solution accords with Greenwood & Earnshaw (list 0 as common for everybody), but on the other hand, it feels like something is being swept under the rug when 0 would absolutely not be common if it weren't for the pure element (fluorine comes to mind as an extreme case). Double sharp (talk) 15:15, 6 October 2024 (UTC)Reply

I only used the word "exotic" as the opposite of "main" or "common". I don't think we should use that word for exactly the reason you point out. Exotic implies a rather more extreme distinction than merely less common. Nevertheless 0 state for Cr and Fe is not "common" and would not appear in their "common" list. Johnjbarton (talk) 15:25, 6 October 2024 (UTC)Reply

What do we mean by "exotic", though? Fe(CO)₅ is produced industrially as an intermediate in making pure iron by a carbonyl process, although that's not a common way to do it. Does that count? What about the common usage of carbonyls as examples to teach the 18-electron rule; does that make them sufficiently non-exotic? It seems we need some kind of delimitation from RS. At the very least, I think that if you're not going to consider Ni(0) and Pt(0) common, then one should not consider Pd(0) common either, so probably something should be done about the table in Oxidation state (which I notice doesn't cite anything for bolding Pd(0)). Double sharp (talk) 15:31, 6 October 2024 (UTC)Reply

I go with exclude all free element's 0. There should be no double standards towards noble gases, we can't include noble gases's 0 oxidation state in the infobox, but excluding others. Nucleus hydro elemon (talk) 15:28, 6 October 2024 (UTC)Reply

I agree. Double sharp (talk) 15:31, 6 October 2024 (UTC)Reply

Coming in late to the party (via Talk:Lithium, I support dropping the commentary (parenthetical highlighting the nature of certain oxides) in the "oxidation state" field, since that is not intrinsic to the oxidation state but instead to certain compounds of them. I support keeping the common and rare, with some sort of distinction between them, since that is a good overview of lots of chemistry. I oppose including 0 solely for standard state, since that does not provide any useful information or identifying characteristic of each specific element (the purpose of an infobox). The full Template: list has refs for all (or at least all the non-major ones). It shouldn't be hard to re-engineer that template to take an optional parameter (if specified, just return the IB segment for that element; else return the whole formatted table). That would mean no duplication of content, and easy transclusion of the set of refs for the exotics in the infobox. DMacks (talk) 15:32, 6 October 2024 (UTC)Reply

"It shouldn't be hard to re-engineer that template..." great so I will be calling on you when the going gets tough ;-) Johnjbarton (talk) 16:02, 6 October 2024 (UTC)Reply

Did it in about 2 hr, including first reverse-engineering some of the element-infobox spaghetti from scratch, as {{Oxidation state}}. Someone just needs to merge the predicted ones from {{Infobox element/symbol-to-oxidation-state}} to the |pred= parameter of that new template (along with the relevant refs). What do I win? Note: does not yet do bolding of most-common of predicted (should really do this string slinging in Lua where we can do temp variables and more direct string-parsing. DMacks (talk) 06:47, 8 October 2024 (UTC)Reply

I have added those predicted oxidation states. I am not sure are Cn(0), Fl(0), and Og(0) predicted to have compounds, or are just free elements. Nucleus hydro elemon (talk) 08:12, 9 October 2024 (UTC)Reply

I have not heard of predictions of such compounds. (Is Hg(0) even known in a compound? That might be the best comparison for Cn and Fl.) More likely it is about various forms of the Pitzer prediction that 112, 114, and 118 should be relatively inert noble-gas-like elements. Double sharp (talk) 11:56, 9 October 2024 (UTC)Reply

I guess the going didn't get that tough after all :) DMacks (talk) 19:41, 14 October 2024 (UTC)Reply

oh, well as they say "I learned a lot". Including that I don't want work with templates again ;-) Johnjbarton (talk) 02:04, 15 October 2024 (UTC)Reply

Anyway, here's the whole G&E list (where I removed 0 since they seem to be assuming it for every element as the simple substance). Does anyone have any particular objections to it?

A few objections I can think of:

1. There are a ton of obvious organic cases where carbon takes on an oxidation state not listed by G&E as "main", e.g. ethane immediately gives −3 and it's hardly exotic. On the other hand, I suppose that the oxidation state is not really the most useful concept when we start talking about those cases. A similar problem appears with cluster chemistry (important for boron and a bunch of early d-block metals), and perhaps things like carbonyl complexes.
2. There's a few borderline cases where G&E may be too harsh in its exclusions, like V(IV), Re(VII), or U(IV). And also a few cases where G&E might be too lenient, like Sn(−IV). This is not an argument in the absence of RS, but at least suggests that we should try looking for more sources than G&E, to get a more representative picture of the literature.
3. There's a few cases in the extreme radioactives when later research suggests G&E's choice is not correct: At (where current work shows +3 more stable than +1 in aqueous solution), Md and No (where +2 is at least as important as Eu). There's also the point that chemistry now exists past Rf. But how can we really know what "main" is for these elements that can only be produced one atom at a time – and, in the case of Lr onward, when only one oxidation state is known? Is that a different situation for Lr and Rf, where periodicity implies that that's exactly what you would expect to see, and for the others, where especially for Bh and Hs comparisons with Re and Os indicate that we don't have the full picture? And how is any of that comparable with elements for which solutions can be examined at more typical concentrations and bulk crystals are a thing that you can produce? On the other hand, G&E are treating them on a par with the normal ones, perhaps as a simplification. Should we just do it anyway because the source does?
4. Kr(II), Xe(II), Xe(IV), and Xe(VI) do not seem to fit a reasonable definition of "main". My intuition would object that any definition where Kr(II) is main should presumably include Fe(VI). And it also doesn't make a lot of sense to allow Xe(VI) in but not Rn(II), when periodicity implies (and experiments somewhat confirm) that Rn is more reactive than Xe. Perhaps we should go with Johnjbarton's idea and depart from G&E for the noble gases in favour of common sense.

Double sharp (talk) 16:13, 6 October 2024 (UTC)Reply

I object if it doesn't include the newer cases various editors add to the Template: as they are found in recent literature. DMacks (talk) 21:56, 6 October 2024 (UTC)Reply

@DMacks just in case you missed it, I'm pretty sure Double sharp is referring only to the "common" oxidation state. We are proposing a two layer presentation where 1) the common values are sourced to G&E or similar to represent "stable", "historic", or well "common" oxidation state and 2) the rest ("less common", "recent" "newsy") are sourced to recent literature. Johnjbarton (talk) 22:07, 6 October 2024 (UTC)Reply

Thanks for the clarification...was definitely not how I read DS's comment. I can definitely support using G&E or similar for some sort of main/common OS list. DMacks (talk) 23:01, 6 October 2024 (UTC)Reply

Superheavy elements use predictions on infobox, so I guess predictions can also be used in Rn and solve (4). Currently, the main references for predictions at those superheavy element articles are ^[1][2]. I have no access to the former, and the latter is really old. Nucleus hydro elemon (talk) 06:52, 7 October 2024 (UTC)Reply

@Nucleus hydro elemon: I have access to the 4th edition of that work through my university library. These are the given predicted "stable oxidation states" from table 14.10 in that book (for some reason, only elements up to 109 were named):

Z	Sym	Main oxidation states
104	Rf	4
105	Db	5
106	Sg	6
107	Bh	7
108	Hs	8
109	Mt	3
110	Ds	0
111	Rg	3
112	Cn	4,0
113	Nh	1
114	Fl	2
115	Mc	1
116	Lv	2
117	Ts	1
118	Og	4
119	Uue	1,3
120	Ubn	2,4
121	Ubu	3

Note: These are the states marked as "most stable in gas phase" or "most stable in aqueous solution" or both. The tables (some of these were sourced from 14.15) list all potential oxidation states. Reconrabbit 18:01, 15 October 2024 (UTC)Reply

As far as I can tell, this table is contains the "most stable in the gas phase" of the predicted oxidation states, correct? Johnjbarton (talk) 18:27, 15 October 2024 (UTC)Reply

I added the values up to Mt to the new data template, based on the ref Johnjbarton (talk) 18:48, 15 October 2024 (UTC)Reply

This is a discussion to create a large number of anchored redirects to the lists of isotopes. –LaundryPizza03 (dc̄) 00:58, 5 October 2024 (UTC)Reply

Can you explain what is going on in that discussion? What is the effect of these edits? (As far as I can tell this change is already underway). Johnjbarton (talk) 01:42, 5 October 2024 (UTC)Reply

We're trying to decide what kind of anchor to use for the isomers. I also want to create redirects from symbols, such as Pu-241, where they don't conflict wth other topics, but for the A-first orderings I'm unsure how to handle the ambiguity of "122In". –LaundryPizza03 (dc̄) 01:58, 5 October 2024 (UTC)Reply

I have a prototype for a new approach to oxidation state data.

This design has a single database for Infobox element content and for the List of oxidation states of the elements. The database is organized in three sections, each selected by the element symbol. The selections create data strings for formatters that add markup for presentation. The formatter for the two targets can be changed independent of the data base and each other.

Please review the prototype as a design. This includes the page naming, role of pages, potential shortcomings etc.

If this is acceptable, a lot of steps follow:

1. Move the prototype templates into template space, adjust content for move.
2. Call the {{List of oxidation states of the elements}} in the data/doc page.
3. Verify that the draft list rows are what we want to see.
4. Fill in the data, merging the two sources (and possibly discarding unsourced states?)
5. Sandbox the switch to new infobox entries.
6. Turn on new version.
7. Consider adding testcases.

I'll sign up for the first two and ask for help to finish. Johnjbarton (talk) 18:11, 10 October 2024 (UTC)Reply

I pushed a new set of templates for oxidation state data. The content of List of oxidation states of the elements is now derived from {{Element-symbol-to-oxidation-state-data}}. The references in this content were copied out of Template:Infobox element/symbol-to-oxidation-state. That template will be replaced shortly with one based on the new data set. At that point both presentations of the oxidation state data will be based on the same data. Johnjbarton (talk) 19:23, 14 October 2024 (UTC)Reply

Great! The List-of... table has a few bugs in the Notes column:

• Elements 42–44 are throwing red error messages

  Seems to have cured itself...maybe when I purged.

• Element 54 has text other than refs (should be a <ref>...</ref>?).
• Element 104 has some visible parentheses.
• Element 104 has an unresolved named-ref "Haire".

DMacks (talk) 19:44, 14 October 2024 (UTC)Reply

I did not spend a lot of time on the high elements numbers with predicted oxidation states. I'm just guessing, but the predicted oxidation states are likely to be one result in one primary publication. I think mostly these would be better handled in the article text to explain the concept of the prediction. Johnjbarton (talk) 22:32, 14 October 2024 (UTC)Reply

I'm confused by the /sandbox usage. I copied the existing {{Infobox_element}} into {{Infobox_element/sandbox}} and changed the sandbox version to call the new backend processing. Then I copied {{Infobox iron}} into {{Infobox iron/sandbox}} into {{Infobox iron/sandbox}} and changed the first line to call {{Infobox_element/sandbox}}. But I get inconsistent results. I seems to have taken my first change but after that my changes seem to have no effect?? Johnjbarton (talk) 22:55, 14 October 2024 (UTC)Reply

I gave it sticky-headers. Not related to the current back-end overhaul, but useful for readers for a long table regardless of how the table is generated. DMacks (talk) 19:46, 14 October 2024 (UTC)Reply

{{Infobox iron/sandbox}} has an example of the new code driving an element infobox. Johnjbarton (talk) 02:02, 15 October 2024 (UTC)Reply

I've updated {{tl:Infobox element}} to use the new backend. Please let me know of problems. Two I know about:

• Most elements have unsourced oxidation states which show up as lots of ? linked to WP:citation needed. We could agree to delete them instead. Or reference them. I guess review sources on individual elements would be good sources.
• The hypothetical elements beyond 112 are not correctly listed. I was unsure what should be done.

Johnjbarton (talk) 17:52, 16 October 2024 (UTC)Reply

Elements from Nh to Ubh are all correctly displayed now. Nucleus hydro elemon (talk) 06:50, 18 October 2024 (UTC)Reply

This change has broken references for at least a few articles. Is there a fix planned? Why weren't the changes adequately tested to prevent that? For an example, see Nihonium, which has more than two dozen undefined reference errors. <ref name="Haire"> was previously defined by invoking {{infobox nihonium}}, but this recent edit by Johnjbarton changes the inclusions to a template that no longer provides those references. Now, they're undefined. Roentgenium has similar damage. Also, Seaborgium, Ruthenium, Meitnerium, Moscovium, ... -- mikeblas (talk) 15:18, 25 October 2024 (UTC)Reply

I tested the changes as well I could. The way the system works certain kinds of issues can't be tested without deploying only then if someone notices the problem as you have done. (Thanks!)

References in particular are nasty business in this system so we have to work around issues. If the refs are defined in the oxidation state data they may duplicate those in the article; if not they may be missing. The only solution for refs needed in both places is to add the definition to the reflist ref= parameter in the References article and use <ref name="Haire"/> in the oxidation state data.

I could not find the definition of Hoffman-2006 in the old implementation. I believe it is the same as the one weirdly named "Haire":

• Hoffman, Darleane C.; Lee, Diana M.; Pershina, Valeria (2006). "Transactinides and the future elements". In Morss; Edelstein, Norman M.; Fuger, Jean (eds.). The Chemistry of the Actinide and Transactinide Elements (3rd ed.). Dordrecht, The Netherlands: Springer Science+Business Media. ISBN 978-1-4020-3555-5.

I think we should change the ref name. Johnjbarton (talk) 16:23, 25 October 2024 (UTC)Reply

I fixed the ones you listed. Let me know if you find others. Johnjbarton (talk) 16:59, 25 October 2024 (UTC)Reply

Thanks for the fixes! But there are at least a few others: Darmstadtium, Bohrium, Copernicium, Unbibium, Flerovium, Hassium, Livermorium, Roentgenium, Ununennium, ... maybe there are more. You can look through Category:Pages with broken reference names to see if you can spot more.

{{infobox element}} previously invoked {{Infobox element/symbol-to-oxidation-state}}, which provided several citations, including "Haire". But a recent change to {{infobox element}} has it now invoking {{Element-symbol-to-oxidation-state-data}}. But that new template no longer defines "Haire", and some of the other citations. Am I missing something, or wasn't it foreseeable that this change would cause errors, since the expected citations would no longer be produced? In all of the cases, the article is decorated with a visible error message about the undefined reference(s). -- mikeblas (talk) 01:49, 26 October 2024 (UTC)Reply

The new scheme is also used for the List of oxidation states of the elements which appears in Oxidation state. If every element in your list includes a def for "Haire" then Oxidation state will have that many duplicate definitions. So the oxidation state data should not have defs, only refs and the defs should be in the articles. Including defs in the oxidation state data is also error prone because editors of the element pages will have to work hard to find the ref def.

Was it foreseeable that some refs would be messed up? Maybe if I was smarter.

Personally I think we should not be presenting oxidation states for these elements: they never form oxides. But the fix up is easy enough I work on it. Johnjbarton (talk) 02:25, 26 October 2024 (UTC)Reply

Well, if the expectation was that articles would define references that were previously made by templates, then it seems like almost any article using the template would need to be examined. That's a pretty risky change.

Goin' forward, tho, I'm no kind of chemist past twelfth grade, so I can't say anything about the propriety of oxidation states in the articles.

There's a couple of other errors left; "Pyykkö2011" isn't defined in Unbibium, for instance. Looks like it might also have been coming from these templates. -- mikeblas (talk) 03:52, 26 October 2024 (UTC)Reply

"VI" (see Copernicium), "Schwerdtfeger" (see Flerovium), "hassocene" (see Hassium), and "hepta" (see Roentgenium) are more citations that have gone missing. Previously, they were all defined in {{Infobox element/symbol-to-oxidation-state}}. Some of these still have problems with "Haire" being undefined. Is there some fix pattern that I can help with to get thes problems sorted across the affected articles? -- mikeblas (talk) 14:24, 26 October 2024 (UTC)Reply

If I understand correctly, the problems resulted by named refs being used in the template that were not defined in the article.

It seems to me that a template should not depend on any refs being defined elsewhere; rather, a template should stand on its own without such a dependency. It would be good, however, for a template to provide a name for every reference it defines in case a transcluding article wishes to use it.

With this convention, the only potential error would be defining a named ref multiple times; a reasonable naming standard would avoid this issue.

— YBG (talk) 22:54, 26 October 2024 (UTC)Reply

I think it's the other way around. The template used to define references, and the article used them. The template stopped producing those references, and now there are undefined reference errors popping up.

Some have been cleaned up, but there are still many errors around as a result of this change.

Johnjbarton, here is another batch of errors: Unbibium (for "Pyykkö2011"), Unbihexium (for "Pyykkö2011"), Unbinilium (for "Pyykkö2011" and "Haire"), Unbiquadium (for "Pyykkö2011"), and Unbiunium (for "Haire" and "Amador"). Again, let me know if I can help. I don't know if you're manually adding the references to the articles, or if you plan to restore them to the template, or ... -- mikeblas (talk) 00:23, 27 October 2024 (UTC)Reply

"The template used to define references, and the article used them." As I have been trying to explain there used to be two templates. One defined some refs that were used in articles but the other did not. I was unlucky in basing my refs on the the other database which did not list these non-elements.

Placing the definitions in the database has two issues:

1. When incorporated into Oxidation state refs defined in different elements will results in duplicate refs
2. When less experienced users look for the definition of the ref in the article they won't find it, it's very mysterious.

Placing only references in the database has two issues:

1. Defs have to be copied into two articles, the element and Oxidation state
2. Failure to do the previous step leads to cite errors.

I chose this path because editors changing the database have enough experience to do the double copy and the missing citations are big red errors that can be noticed and fixed but duplications are tedious to find and fix.

Just to reiterate: refs in the database and defs in 1) element article 2) Oxidation state.

I will update the documentation and ping you to check it for me. Then I'll work on the non-elements. Johnjbarton (talk) 01:13, 27 October 2024 (UTC)Reply

Thank @Mikeblas. I've fixed all of these I believe. Johnjbarton (talk) 23:51, 27 October 2024 (UTC)Reply

Looks good! Thanks for sticking with it!!1! -- mikeblas (talk) 01:12, 28 October 2024 (UTC)Reply

In general the unreferenced oxidation states are also listed by Greenwood and Earnshaw – just as less common ones. Here's the list of uncommon oxidation states listed by G&E on p. 28.

So the "citation needed" tags for these states should be replaced by a reference to the same G&E page that gives the common states. Double sharp (talk) 08:05, 17 October 2024 (UTC)Reply

I have done this.

A bunch more were actually cited in the previous versions. On the other hand, there is a particular issue here. The source for Al₃BC (the first problematic case) never mentions the oxidation states in the compound. I presume the logic behind the B −5 entry is that this should have Al +3, C −4, B −5, but it's not explicitly stated. So now I wonder if it should be considered acceptable to derive unstated oxidation states from IUPAC's rules (doi:10.1515/pac-2015-1204). I might note that the IUPAC report in question remarks that there are quite a few cases where OS assignment becomes either truly ambiguous or formal beyond the point of usefulness, such as in metallic compounds (AuNCa₃), complexes with non-innocent ligands, and cases with very low electronegativity differences (e.g. carbon diselenide).

Personally, I think we should not derive such states ourselves, no matter how obvious the result looks. A particular pitfall is mentioned by this article: Cs₂Pt and BaPt both look like stoichiometric ionic compounds, but only the first is really well-described that way (the second has Pt–Pt chains). Double sharp (talk) 08:30, 17 October 2024 (UTC)Reply

Thanks!

"A bunch more were actually cited in the previous versions. " links the presentation of the older data which has citations in the last column but many states are listed in the row that do not correspond to any ref. Still some of these refs could be useful. Johnjbarton (talk) 15:56, 17 October 2024 (UTC)Reply

I will try to look through them over the next few days. :)

In general, probably G&E should be enough for most of those in the above table. However, in some cases of exotica I'd very much like to back them up with an additional source – I am unaware of a single actual example of Li(−1), and G&E p. 99 remarks on sodides, potassides, rubidides, and caesides but notably not lithides. So I would very much like to know what they had in mind. Double sharp (talk) 16:19, 17 October 2024 (UTC)Reply

For −5, see p. 139. Burzuchius (talk) 09:43, 17 October 2024 (UTC)Reply

@Burzuchius: Thanks. Not sure how I missed that page. In that case, I withdraw my objection to B −5, though I'd still argue for only including oxidation states if they are stated by the source. Double sharp (talk) 12:31, 17 October 2024 (UTC)Reply

I agree with using only sourced oxidation states not ones based on editor analysis. Johnjbarton (talk) 15:52, 17 October 2024 (UTC)Reply

The only known (not predicted) transactinoid oxidation states past Rf are Db +5, Sg +6, Sg 0 (hexacarbonyl; oxidation state however not explicitly mentioned, though I suppose one could plead that it's obvious since it's said to be homologous to the Mo and W versions), Bh +7 and Hs +8 (mentioned as the highest formal oxidation state in the Sg 0 ref).

For completeness here are two borderline cases which I think should not yet be in the list. There is a report on CnSe from 2015, which would presumably be Cn +2 (implied to be homologous to HgSe). However, in a 2016 conference it was stated that further experiments are ongoing to elucidate what's happening (and also to compare with Fl). I have not seen anything more recent on this. Probably NhOH (which would be Nh +1) was formed in experiments probing Nh chemistry (doi:10.1140/epja/i2017-12348-8, noting homology to Tl), but it is not securely identified. Well, what can I say: chemistry with such short-lived species is hard. Double sharp (talk) 16:31, 17 October 2024 (UTC)Reply

There are extraneous commas after the last oxidation state in each list, which is ungrammatical. –LaundryPizza03 (dc̄) 04:21, 19 October 2024 (UTC)Reply

All these commas are removed. Nucleus hydro elemon (talk) 14:39, 27 October 2024 (UTC)Reply

I recently found a 2023 paper from the FRIB collaboration that describes a new isomer of sodium, which is more recent than NUBASE2020 and outside the scope of the Discovery of Nuclides Project (which does not distinguish ground states and isomers). Can anyone find another post-2021 paper that describes a new isomer and isn't already cited on Wikipedia? –LaundryPizza03 (dc̄) 04:18, 19 October 2024 (UTC)Reply

Also, I'd like help on finding every peer-reviewed FRIB publication that includes new measurements of nuclei. –LaundryPizza03 (dc̄) 04:30, 19 October 2024 (UTC)Reply

I'd imagine this would be useful, a review published earlier this year: 2023 update of the discoveries of nuclides The paper is on arXiv here and describes 116La, 27O, 28O, 9N, 241U, 190At, 189Lu, 191Hf, 192Hf, 156W, 160Os, 276Ds 272Hs, 268Sg. Reconrabbit 19:54, 19 October 2024 (UTC)Reply

Isn't this from the Discovery of Nuclides project? Double sharp (talk) 05:00, 20 October 2024 (UTC)Reply

That it certainly is – and I believe all those nuclides are already included on WP. All I can do is periodically check journal websites for anything that hasn't made it to Discovery of Nuclides yet, and if necessary, take a trip to my local library. ^Complex/_Rational 16:21, 20 October 2024 (UTC)Reply

It is mentioned that modern groups 8-10 were called VIII / VIIIB collectively. But what if someone needed to split this group apart into three columns before the modern 1985 numbering system of 1-18? What would they have used? I'm guessing something ridiculous like VIIIa (or VIIIBa), b, c? Is there any data on how this was done back in the day so that it might be put into the article on groups in the periodic table? I'm curious and cannot yet find any information on this. 108.160.120.147 (talk) 03:12, 23 October 2024 (UTC)Reply

There are a lot of edits that violates WP:SULF recently. Although they are actually trying to help to change the article into the same variant of English, we have to address that changing Sulfur → Sulphur is unnecessary. Do we need an edit notice or an edit filter for this problem? Nucleus hydro elemon (talk) 13:26, 24 October 2024 (UTC)Reply

I've occasionally taken a whack at SULF corrections. One gray area I hit is in terms of scope, when an article is not a science article but does have some small science content more than just a passing mention. "These spellings should be used in all chemistry-related articles on English Wikipedia, even if they conflict with the other national spelling varieties used in the article." DMacks (talk) 14:58, 24 October 2024 (UTC)Reply

I added a notice to Talk:Iodine before I saw this note. I don't know if it will help, but it is easy to do.

In my opinion an article that discusses "sulfur" as a material has become a chemistry article, ie unless it is about the word "sulfur". Johnjbarton (talk) 15:24, 24 October 2024 (UTC)Reply

I created an edit notice for that, but soon I found that I don't have the permission to add it into articles. Nucleus hydro elemon (talk) 15:15, 25 October 2024 (UTC)Reply

@Nucleus hydro elemon, Johnjbarton, and DMacks: I added this edit notice to the element articles in question. Not sure if it will be necessary for all isotope- and compound-related pages as well, and if so, if there's a more efficient way to add one. ^Complex/_Rational 15:31, 25 October 2024 (UTC)Reply

All elements needs the edit notice, so do all aluminium, sulfur, and caesium compounds. As "sulfuric acid" is common in chemistry, the list will be even more extended. Nucleus hydro elemon (talk) 16:16, 25 October 2024 (UTC)Reply

https://iupac.org/standard-atomic-weights-of-three-technology-critical-elements-revised/ 108.160.120.147 (talk) 17:48, 24 October 2024 (UTC)Reply

Thanks for the heads up! Updated. :) Double sharp (talk) 03:43, 25 October 2024 (UTC)Reply

The infobox image for nitrogen is liquid nitrogen. The image for oxygen used to be liquid oxygen, but @Hexonite: changed it to the discharge tube here without explanation (I would like to change it back but first should ask why you changed it). All the noble gases have discharge tubes, but Wikimedia Commons has images of liquid argon available at commons:Category:Liquid argon, and liquid helium at commons:Category:Liquid helium. There are images of liquid xenon here, here, and here. So, if an image of the liquid element is available, should we use that instead of the discharge tube, and only use the discharge tube if no image of the liquid element is available? This was previously discussed at here in 2009, because at the time these articles were using images of empty vials containing the colorless gas. HertzDonuts (talk) 22:50, 27 October 2024 (UTC)Reply

Hexonite doesn't appear to be very active, so I have changed the image at Template:Infobox oxygen back to liquid oxygen for now. Waiting for input from others before changing the images for helium, argon, and xenon. HertzDonuts (talk) 23:06, 27 October 2024 (UTC)Reply

I am reluctant for the change of noble gases without neon and krypton. The infobox at the article Noble gas will have a weird mix of liquids and discharge tubes. Nucleus hydro elemon (talk) 08:02, 28 October 2024 (UTC)Reply

hmm, I guess that really is something to think about

I only updated it to better represent oxygen being thought of as a gas, rather than a liquid.

If anything, these pages should have pictures of all of the phases (because it's the same element and molecule), however if that's impossible, only pictures of their current phase.

lets say water is a liquid and freezes to become ice, is water more thought of as a liquid or a solid? Everyone knows that water freezes to ice, but does the liquid form come to mind first or the solid form when you think of water?

Yeah that was my logic here.

AND that's what I think the noble gases pictures should be. Noble gases, not liquids. Hexonite (talk) 14:36, 28 October 2024 (UTC)Reply

And yes, light produced from an Oxygen molecule never comes to mind when you think of Oxygen

On second thought I would probably suggest that the gaseous elements have a photo detailing the molecule, for instance H2 is H - H two Hydrogen atoms that if represented would be represented as two circles with a line connecting them to visualize the bond.

That would be even better. If I had to choose, I would say the discharge tubes, but that's a suggestion too. Hexonite (talk) 14:43, 28 October 2024 (UTC)Reply

I can see an argument that the infobox picture should show the element's standard state (maybe a collection of allotropes in cases like carbon and phosphorus). In that case, perhaps colourless gases should not have a picture in the infobox as well, since they are inherently unphotographable in the standard state, and should instead have pictures illustrating them in other ways in the body? It's similar to how I'd expect true-colour images for Solar System objects in their infoboxes, even if in the case of Venus the result is really boring. Double sharp (talk) 04:33, 29 October 2024 (UTC)Reply

However, some image is always better than no image. If it's a transparent gas, I'd rather have some kind of container and explanation over "no image". 108.160.120.147 (talk) 19:01, 29 October 2024 (UTC)Reply

The oxidation state data for six "elements" relies on this source:

• Pyykkö, Pekka (2011). "A suggested periodic table up to Z ≤ 172, based on Dirac–Fock calculations on atoms and ions". Physical Chemistry Chemical Physics. 13 (1): 161–8. Bibcode:2011PCCP...13..161P. doi:10.1039/c0cp01575j. PMID 20967377.

However, when I read the source I conclude that no such data is present there. The section "5. Ionization potentials and oxidation states" in the paper is chicken and waffles as far as I can tell. I am unable to verify the existing data based on this source. Johnjbarton (talk) 23:18, 27 October 2024 (UTC)Reply

See table 7. The oxidation states are implicitly stated by referring to formal electron configurations, i.e. "8s⁰5g⁰" for 121X₃, 122X₄, 123X₅, 124X₆, 126O₄. Section 5 refers to predictions varying for 126. Then again, since these lists of compounds are not explicit OS statements, and they are presumably not exhaustive, perhaps they should be removed anyway and left to the text. (Also, strangely I can't find 126(VI) mentioned there. The hexafluoride is discussed in another paper by Dognon and Pyykkö, though.) Double sharp (talk) 02:28, 28 October 2024 (UTC)Reply

I am proposing that the "Other sets" section of the sidebar be subdivided up as shown at {{Sidebar periodic table/sandbox}}. The current layout {{Sidebar periodic table}} is visible in the documentation below my proposal. Comments? — YBG (talk) 23:53, 28 October 2024 (UTC)Reply

Did you consider grouping all of the periodic chart categories together? The "... periodic table position" could be "Named groups", "Other groups" or "Other named groups" under "By periodic table structure". Johnjbarton (talk) 01:43, 29 October 2024 (UTC)Reply

That’s a good idea, and no, I didn’t consider it. The three categories under periodic table structure are each currently mutually exclusive and jointly exhaustive, so moving this section would be a little tricky, but probably doable. I’ll have a go at it. YBG (talk) 02:52, 29 October 2024 (UTC)Reply

@Johnjbarton What do you think of it now? YBG (talk) 03:03, 29 October 2024 (UTC)Reply

Looks good to me! Johnjbarton (talk) 03:13, 29 October 2024 (UTC)Reply

@JJB: Under Other sets, named for ... we have:

... element uses
Coinage, precious, and refractory metals

... element properties
Heavy and light metals * Noble metals

But I’m wondering if that last would be better:

... element properties
Heavy, light and noble metals

Thoughts?? YBG (talk) 04:29, 2 November 2024 (UTC)Reply

Also good. Johnjbarton (talk) 16:15, 2 November 2024 (UTC)Reply

There are still many referencing templates with errors. (Are these templates actually in use, or should they just be deleted anyway?) These templates all have undefined reference errors in themselves -- that is, right at their template pages, or their own documentation pages. These seem to be related to oxidation states:

• {{Element-symbol-to-oxidation-state-data}}
• {{Element-symbol-to-oxidation-state-data/doc}}
• {{Element-symbol-to-oxidation-state-entry}}
• {{Element-symbol-to-oxidation-state-entry/doc}}
• {{Element-symbol-to-oxidation-state-row}}
• {{Element-symbol-to-oxidation-state-row/doc}}
• {{Element-symbol-to-oxidation-state-row/sandbox}}

Here are element-specific templates that also have referencing errors built-in:

• {{Infobox copernicium}}
• {{Infobox flerovium}}
• {{Infobox hassium}}
• {{Infobox livermorium}}
• {{Infobox meitnerium}}
• {{Infobox moscovium}}
• {{Infobox nihonium}}
• {{Infobox roentgenium}}
• {{Infobox tennessine}}
• {{Infobox unbibium}}
• {{Infobox unbihexium}}
• {{Infobox unbinilium}}
• {{Infobox unbiquadium}}
• {{Infobox unbiunium}}
• {{Infobox ununennium}}

It seems like bad form to have referencing errors in a template's example invocation in its own page. I don't think these pages were a problem until some changes were made last week. How can this all be set right? -- mikeblas (talk) 00:16, 31 October 2024 (UTC)Reply

Solving this problem will unfortunately create other problems. These two problems are 1) mysterious references, 2) silent failure modes.

1) When I altered the template implementations I changed a few references and the result was errors in many element pages as you know. The reason was that these element pages used <ref name="Haire"/> but no where in the element page was "Haire" defined. I did not realize what was going on and I guess I have more than the average experience with references in wiki pages.

2) When working on this problem I encountered cases where a reference was included twice I guess because an editor did not know where to look for the definition of the reference.

For these reasons I think we should define reference in the final end point page and not in the template data base. There are two down sides to this solution: 1) twice as many definitions (element and oxidation state 2) errors in template documentation pages that you see above.

In my opinion we should adopt the solution that puts the burden on editors who work on templates as they are more likely to know the issues or at least know how and where to ask about them.

However if there is a consensus to place definitions in the database I am fine with it.

We could solve the errors in the template documentation pages by adding ref-defs in these templates, but I would oppose this solution because it would be three places defs have to be added.

I also just had a thought: what if we got rid of the oxidation state database and put the oxidation state data into each element's infobox instead? It might be possible to build the List of Oxidation State table by processing the infobox for all the elements. This would be a lot less complex for editors than tracing through {{infobox element}} Johnjbarton (talk) 01:23, 31 October 2024 (UTC)Reply

I think the refs should be defined in the template (or the OS db if you prefer). There should be a list of named references in two places: in the template’s doc page and in the element's talk page. This could be done creating a subpage of the template and transcluding it in both places. This would provide two places for an editor to find out about named references available for use.

But even if an editor doesn’t know about the names refs, they would not be burdened. Editors should not be adding a reference unless they have access to the original source, and if they have access to the original source, they have all the information they need to create the footnote.

The only possible problem would be if an editor tried to define a named ref that is already defined in the template. This can be avoided by having all ref names defined in element templates named appropriately. I suggest something like ElemTemplate_Smith or ElemTemplate_Smith1969. An editor who wants to add a couple of statements supported by Smith and decides to add a named reference would create ref named Smith or Smith1969. There would be no duplicate definitions. A more experienced editor would notice that Smith is unnecessarily listed in multiple footnotes and could correct the issue.

— YBG (talk) 03:50, 31 October 2024 (UTC)Reply

• "I think the refs should be defined in the template (or the OS db if you prefer). " That combined with mikeblas' complaints is enough to convince me.
• "There should be a list of named references in two places: in the template’s doc page and in the element's talk page. This could be done creating a subpage of the template and transcluding it in both places."

? These refs would not appear in the elements page or oxidation state list. Johnjbarton (talk) 15:34, 31 October 2024 (UTC)Reply

What is "the database"? I guess that's the same thing that YGB means by "the OS db"? -- mikeblas (talk) 04:20, 31 October 2024 (UTC)Reply

When I said 'database' I meant {{Element-symbol-to-oxidation-state-data}}. Johnjbarton (talk) 15:35, 31 October 2024 (UTC)Reply

Ok all of the templates are fixed. The element Darmstadtium has a duplicate citation for some reason that I can't figure out. Johnjbarton (talk) 16:45, 31 October 2024 (UTC)Reply

Does it have something to do with how electron config is transcluded into the infobox, or the excerpt from superheavy element? Reconrabbit 17:20, 31 October 2024 (UTC)Reply

Wow, that was a doosy! I tracked down the duplicate reference to {{Infobox element/symbol-to-electron-configuration/ref}}, which had a slightly different definition of that "Haire" citation. I think it is fixed now, with this edit. Did my fix cause any collateral damage?

This "Haire" reference is used all over the place. Would it be a good idea to give it is own template, so it can be defined at one place in the template, then invoked repeatedly all over? Then, the repeated definitions would always match. If the ref ever needs to be updated, it is in one place. (OTOH, if only some articles need a change to the reference, then more complexity arrives.) -- mikeblas (talk) 19:25, 31 October 2024 (UTC)Reply

But I don't think we're out of the woods. Several other artilces (like Dubnium and Bohrium and Rutherfordium and Samarium and ...) have duplicate ref def errors for "Haire". -- mikeblas (talk) 19:31, 31 October 2024 (UTC)Reply

I've fixed rutherfordium, seaborgium, dubnium, and bohrium. -- mikeblas (talk) 21:49, 31 October 2024 (UTC)Reply

I guess you meant {{infobox rutherfordium}} etc. I don't think those changes have the effect you think they do. Making the text content of two refs identical has no effect on anything other than the changed ref content. Both defs will still appear where ever they appeared before. Johnjbarton (talk) 22:17, 31 October 2024 (UTC)Reply

Yes, I made fixes at the infoboxes. If a <ref> tag is exactly the same as another, it is combined into the same reference -- but only if exactly the same. If the same values are in the same parameters, just in a different order, that's not exactly the same, and a duplicate definition error appears.

And further: if that reference definition is wrapped in a template, it will consistently be generated and never cause a duplicate reference definition error.

Can you please help me understand your reversion of my edit over on the Samarium article? In my version of the article before you reverted my change, there are no duplicate definition errors. When you reverted the edit and re-added the name, a duplicate reference error appears. -- mikeblas (talk) 00:50, 1 November 2024 (UTC)Reply

In your version of Samarium reference 10 and 70 are the same. Your edit just took off the name so there were no longer two defs with the same name but rather one named and one unnamed, two copies. After I reverted your edit, in the next edit I changed the ref def to ref ref: <ref name=Chiera2024/>. Now their is one def (somewhere!) and one ref-ref, and the References list two instances. Does that make sense?

This consistently generated/ref merging thing is new to me, can you point to the docs? Sounds very handy. Johnjbarton (talk) 01:31, 1 November 2024 (UTC)Reply

Oh, I see! I didn't notice a version of the article after your reversion. Maybe I looked while you were editing it, or maybe I didn't refresh.

Notes 10 and 70 in my version aren't quite the same. They have different date formats, and that's one of the things that was different between the citations used to form the references. And, since they were different, that's why the error appeared.

I don't know if the duplicate folding behaviour is documented, but it's readily observable and behaves consistently. -- mikeblas (talk) 09:46, 1 November 2024 (UTC)Reply

Group 5 element has been nominated for a good article reassessment. If you are interested in the discussion, please participate by adding your comments to the reassessment page. If concerns are not addressed during the review period, the good article status may be removed from the article. Z1720 (talk) 13:46, 3 November 2024 (UTC)Reply

A while ago I posted a discussion suggesting that decay energy be added to the tables on "Isotopes of [element]" articles. The discussion never really got to a consensus. I though I might bring it up again because this site lists, as far as I can tell, all known isotopes and decay energies for most decay modes. The one exception is it does not appear to list the energies for cluster decay. Thoughts? TornadoLGS (talk) 19:29, 9 November 2024 (UTC)Reply