Wikipedia talk:WikiProject Elements

Archives: Index 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63

This page has archives. Sections older than 60 days may be automatically archived by when more than 4 sections are present.

Article alerts

Good article reassessments

30 Nov 2024 – Boron (talk · edit · hist) nominated for GA reassessment by Z1720 (t · c) was closed; see discussion
19 Nov 2024 – Actinide (talk · edit · hist) nominated for GA reassessment by Z1720 (t · c) was closed; see discussion
03 Nov 2024 – Group 5 element (talk · edit · hist) nominated for GA reassessment by Z1720 (t · c) was closed; see discussion

Requested moves

19 Nov 2024 – Heavy metal element (talk · edit · hist) move request to Heavy metal (chemistry) by Mdewman6 (t · c) was moved to Heavy metals (talk · edit · hist); see discussion

Updated daily by AAlertBot — Discuss? / Report bug? / Request feature?
Click to watch (Subscribe via

RSS

Atom) · Find Article Alerts for other topics!

FA	A	GA	B	C	Start	Stub	FL	List	Category	Disambig	Draft	File	Portal	Project	Redirect	Template	NA	???	Total
29	0	96	103	127	96	34	0	172	133	0	0	30	0	15	2,195	144	20	0	3,194

TrophyBox

Other sets in sidebar

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]

Referencing problems with element templates

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:

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

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? Recon rabbit 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]

Good article reassessment for Group 5 element

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]

Revisiting decay energy for isotope lists

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]

Good article reassessment for Actinide

Actinide 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) 23:51, 19 November 2024 (UTC)[reply]

Requested move at Talk:Heavy metal element#Requested move 19 November 2024

There is a requested move discussion at Talk:Heavy metal element#Requested move 19 November 2024 that may be of interest to members of this WikiProject. Raladic (talk) 19:17, 26 November 2024 (UTC)[reply]

Good article reassessment for Boron

Boron 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) 02:40, 30 November 2024 (UTC)[reply]

Pulse Radiolysis Studies for Oxidation states

I was looking over some of the old references, and noticed some oxidation states have been stated by observation from pulse radiolysis studies, such as

Kläning, Ulrik K.; Sehested, K. (1986). "Selenium(V). A pulse radiolysis study". Inorganic Chemistry. 90 (21): 5460–4. doi:10.1021/j100412a112.

Should these be included in the list of oxidation states? Keres🌕Luna ^edits! 03:02, 16 December 2024 (UTC)[reply]