Jump to content

Template talk:Chembox/Archive 12

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 5←Archive 10Archive 11Archive 12Archive 13

Conversion Update

So just an update for anyone interested. We have a working replacement for {{Chembox}} at {{Infobox chemical}}. Eagerly looking for feedback on what needs additional work before we roll it out. I've posted in a number of places but have only gotten a few people to chime in.

Improvements
  • Reduces WP:OVERLINK & MOS:DUPLINK. Nearly every label in {{Chembox}} is linked including things like Eye Hazard.
  • In line with WP:ACCESSIBILITY. There are certainly places that things are showing up much bigger than before, but this follows the requirements of WP:ACCESSIBILITY.
  • Fewer templates to maintain. {{Chembox}} has separate templates for nearly every single row in the table, adding up to well over 200 separate templates. WAY more than is necessary.
  • Builds on the style, look and feel of {{Infobox drug}}. The Infobox drug template, formally known as {{Drugbox}} was also converted to use {{Infobox}}. This one uses many of the same styles and subtemplates as that.
  • Implements much better Check for unknown params. The use of Module:TemplatePar is fine, but it has a much more narrow scope and is not nearly as well documented or maintained as Module:Check for unknown parameters.
  • From the editors point of view, works the same. These templates will work exactly the same as the {{Chembox}} series of templates. NO parameters have changed. So apart from having to call {{Infobox chemical}} instead of {{Chembox}}, there is no change to how editors will use the templates. No new parameters & no new syntax. As per the other points made here, there are certainly some stylistic changes to how the template renders, but I want to be clear that for the editor, nothing new except for calling a different template.

Once again, really eager for any and all feedback. Please be sure to look at the testcases as well! --Zackmann (Talk to me/What I been doing) 02:30, 25 November 2018 (UTC)

"before we roll it out". Therefore I have un-marked the existing one as deprecated. If you persist in rolling out a major change that multiple editors have voiced concerns about, you will find yourself blocked for disruption and bad-faith claims of consensus. DMacks (talk) 03:06, 26 November 2018 (UTC)
WOW DMacks. Talk about WP:AGF... Trying my best here. How about you join the discussion instead of just accusing me and threatening me with blocks? --Zackmann (Talk to me/What I been doing) 03:13, 26 November 2018 (UTC)
Disruption is disruption. A major change after others voice concerns (I did and others did as well, even though you explicitly said you were not even interested in receiving such input), and with a major rollout rather than first small-sale testing or even notice that it's happening to the stakeholders is on its face disruptive. WP:CONSENSUS and all that. DMacks (talk) 03:47, 26 November 2018 (UTC)
@Zackmann08: I second DMacks in that: Your behaviour here is disruptive. You are insistent in stuffing this down throats: You start a discussion where many concerns are brought forward, to which you never responded. Then start an RfC with an attempt to shut down any response you don't like. And when that RfC does not go your way, you delete it, and start to convert it yourself. Then you comment, but again do not address cncerns, you go on and mark it as deprecated, and subsequently for deletion withour informing major contributors and the wikiprojects, let alone properly testing it. That behaviour is disruptive. --Dirk Beetstra T C 03:55, 26 November 2018 (UTC)
@Beetstra:[1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13] and the list goes on. I reached out to you both individually asking for your concerns. Instead, you accused me of stuffing something down your throats. I have reverted the deprecation notice. I admit that was preemptive. Now, I have asked for concerns. Instead of just accusing me of being disruptive, can you provide some feedback on the template? Have you even looked at it? --Zackmann (Talk to me/What I been doing) 03:57, 26 November 2018 (UTC)
@Zackmann08: no, I did not have time with you leaving notices over black Friday/Thanksgiving weekend and pushing for deprecation and even deletion. Can you see how we feel you are stuffing this down our throat: First you do not respond to first concerns, then you put up an RfC where you pre-emptively disqualify any answer you don't like (and then delete it), and now you leave notices over the weekend, expecting editors to respond within 24 hours and already put it up for deletion. And you conveniently leave out the initial discussion and RfC from above list. I am sorry, a spade ISa spade: What you have done here is disruptive (even if possibly well-intended) (and especially since it seems that your TfD is in response to the removal of the deprecation, which appears very pointy). --Dirk Beetstra T C 04:17, 26 November 2018 (UTC)

(edit conflict) @Beetstra and DMacks: ok look. Clearly I made a few missteps in this process. Let me apologize for being hasty. Let me also apologize for ANY appearance or implication that I was not open to feedback. There is absolutely no intention to stuff this down anyone's throat. From my point of view, I tried my best to notify people and only removed an RfC when multiple people said the RfC was simply disruptive. I was not trying to hide the comments, I just got frustrated being called an armchair commentator, etc. I don't think it is helpful to go back over past actions. If you want to then by all means you can bring up the mistakes I've made and we can fight over whether I did this properly or not. Etc. Etc. OR, we can work together? I think that the new template I have created will meet the needs of all those interested. That being said, I'm sure there are minor things that I have not thought of. That is why I have asked for feedback from you and other experts in the Chemistry project. There are about 50 or so chemical pages that I manually switched over to use the new template. This were part of the testing process. I scrutinized the before and after and could not find any differences that weren't necessary per WP:ACCESS. However, I'm happy to personally revert each of those changes if you feel it is necessary.

Regarding the TFD, I think it might be helpful to keep the TFD to initiate the DISCUSSION and attract more attention to the process. However, if you feel it is premature, I will gladly withdraw the nomination. Again, I am sorry if my tactics in the past sent the wrong message. I would like to start fresh and work WITH you. I'm going to take a step back. There is no timetable here and that is something I keep forgetting. I'm a "full steam ahead! This works great LETS DO IT!" Kind of guy. I need to stop and slow down. I hope that both of you, and others, will work with us to finish up this template so that it will work for everyone. I'm going to walk away from the keyboard for the night because I'm frustrated and don't want to type anything else when I'm in a bad mood. But I sincerely hope we can bury the past and work together. I truly value any input you have. --Zackmann (Talk to me/What I been doing) 04:21, 26 November 2018 (UTC)

@Zackmann08: withdraw your TfD, give concerned editors and wikiprojects a 1-3 month time to test and consider, and let someone else pull final triggers. You have upset quite some editors this weekend. Step away from implementation. --Dirk Beetstra T C 04:27, 26 November 2018 (UTC)
I have withdrawn the TFD. Sorry for the issues that I caused. If anyone has any questions for me, please feel free to ping me. --Zackmann (Talk to me/What I been doing) 05:53, 26 November 2018 (UTC)
21 days ago the last post was posted here, and since the new template has been used on 20++ articles before DePiep reverted it a few hours ago. It was used on complicated pages like ammonia and diethyl ether, and as infobox for hazards for some elements. It had nearly the same output as the old template, and most important, nobody has been complaining about the template the last 20 days. DePiep reverted without any explanation except "Infobox version not fit nor supported for mainspace". I propose that we switch to the new template which is much less complicated then the old one. It does not have 100+ subtemplates. E.g. diethyl ether with {{infobox chemical}} uses 162 templates, but same page with {{[[Template:|]]}} uses 220 templates. Which means its much easier to maintain, and it has the same layout as other infoboxes on Wikipedia. Christian75 (talk) 05:26, 17 December 2018 (UTC)
For what it is worth, I agree with the reversal of the templates, at least the ones by User:Zackmann08 - most of them were converted while in testing mode, where the templates were still under active discussion and (IMHO disruptively) marked as deprecated and subsequently TfD'd (last conversion in mainspace is after withdrawing the TfD, and I believe that we mentioned that we would not want 10.000+ edits to articles, let template-redirects handle it. IF we want it in the first place.
My suggestion, open an RfC, let it run for 30 days (great, after this whole disruptive push over Thanksgiving weekend, we now get an RfC over X-mas break ... ). Let's see what people think. --Dirk Beetstra T C 06:40, 17 December 2018 (UTC)
  • I'd like to have an overview of actual changes, not just global mentionings as this thread does. Especially those that affect the result (eg visually, content, behaviour). Assumptions and judgements ("x is improved") better be written out to be scrutinised. All this should be on or through this talkpage. There should be testcases. Also, I am missing the grand design setup: the future of {{Chembox}}. (Simple example, why should we edit the articles to apply name change? Why was Redirect not considered?). - DePiep (talk) 11:49, 17 December 2018 (UTC)
:-). This is just a detail of a general change design, now missing. For the current version as it is, dearly absent is the discussion of actual changes. I could go search & list them myself, but that only strengthens the notion that we must pull off such talks, instead of being offered them by the T:-editor(s). IOW, not convinced that such talks would be effective or taken serious. This constellation is why I feel not invited to spend extra time on this. -DePiep (talk) 08:19, 18 December 2018 (UTC)
Zackmann08@. -DePiep (talk) 09:45, 18 December 2018 (UTC)
  • Recap. We are a month later, and Zackmann08, Hike395 still have not responded. They were sincerely invited to start & lead a discussion over the changes proposed & sandboxed, but did not give a diff. Just not responding a single time or moment, while multiple editors posted a compaint or question. (It's not just me). This way, they are abusing other editors energy without helping the issue forward. The option to register a complaint re WP:TE behaviour is still open (That absolute arrogant absence of discussion, and even actively evading it). Also, there are disturbing details like off-talkpage discussion a, b, and posts [14], [15], [16] (note the "this weekend" i.e., before DePiep would return from read-only mode; the mode period Zackmann tried so hard to extend).
I seriously ask these editors to start and lead a change discussion — on this page. RfC or TfD are a bad option: that would invite armchair commentors with free !votes; we need involved editors. And oh, please drop the ownership attitude [17], visibly claimed asap after I was put into read-only mode. -DePiep (talk) 00:55, 29 December 2018 (UTC)
Zackmann08 has asked me to advise all concerned that he has withdrawn from any participation on this page owing to a serious disagreement with DePiep and his belief that further communication of any kind between them is unlikely to be productive. He requests that he not be contacted again. FTR I agree with and support his decision. -Ad Orientem (talk) 01:04, 1 January 2019 (UTC)
Eh, Ad Orientem, AFAIK Zackmann08 is responsible for their own action, as any editor is. Why do you take cause? -DePiep (talk) 03:27, 1 January 2019 (UTC)
He requested my intervention on my talk page. I encouraged him some time ago to cease communication with you given the acrimonious nature of your relationship. I am less than pleased with his comment below, but it is what it is. This is like a really bad B movie that just won't end. Irrespective of whether he is ready to move on, I am. -Ad Orientem (talk) 03:32, 1 January 2019 (UTC)
Zackann08 and I, per mutual WP:NOBAN request, both do not bother mutual talkpages. All fine, all ok. The rest is immature nonsense. This Talk:Chembox page is communal. Zachmann08 is personally able & responsible, even and expressionally so for commenting on this talkpage to improve their Chembox edits. -DePiep (talk) 04:02, 1 January 2019 (UTC)
(edit conflict)I have not responded because I no longer want any part of this discussion. Every single thing I have done has been picked apart and attacked. The comments made above by DePiep (who I am intentionally not pinging as they have requested I not contact them), do not seek a discussion, they seek continued fighting. Alleging that I attempted things while they were blocked (not in "read only mode", you were blocked for the 11th time), or that I'm claiming ownership, etc. etc. I'm just over this. I created a template at {{Infobox chemical}}. Use it, don't use it. Entirely up to you all. I don't own the template, I just wrote the code and it is there to be used. If there are technical questions about how the template works or why (from a technical standpoint) I chose to use a certain feature, users should feel free to ping me directly. But in terms of the politics of this template, I am not interested in taking part in this discussion any longer. Someone else is free to pick up the reins but I am bowing out. Please do not ping me in this thread any more. Best of luck to all. --Zackmann (Talk to me/What I been doing) 01:09, 1 January 2019 (UTC)
re Zackmann08. Yes I was in read-only mode. That implies that you were totally free to edit and discuss, by definition without any interference from me, from day 1. I did not post or canvas, it was all your own doing. Read other editor's posts in this. Then, when I came back on this page, I repeatedly invited you to start a discussion about the changes, esp editor/article's changes and behaviour (as opposed to technical ones). After all, this page is Template talk:Chembox. (I don't think you'll need advice from me, but there is a difference between RfC/TfD versus Talkpage discussion & consensus. The latter handles content). I don't think it is up to other editors like me having to do research to find those changes, and I'm not sure how you'd have received such issues. All in all, this I call evading the discussion, in big and small moments. Diffs aready on this page. -DePiep (talk) 12:49, 3 January 2019 (UTC)
I really wonder what the objections against {{infobox chemical}} is. Look at the testcase, there is a description of this template in the top of this section. It has been tested on approx. 75 pages without any reported problems. It handles images better than our current version, i.e. it does not force image size to be 110 (whoever calls {{Chembox image sbs cell}}) - in matter of fact its one of the problems with out current approch. Its nearly imposible to find which of the 100s templates are responsible for some output. Probably the reason only one editor is editing this template. Christian75 (talk) 01:15, 4 January 2019 (UTC)
re Christian75. My objections are with the proces and its results so far. The editors (Zackmann and Hike395) have not come to this talkpage to propose and discuss actual changes, and so did not strive for consensus. The development process, including all of its discussions, took place out of sight. As a result, we all (editors involved on this talkpage and WP:CHEMICALS) could not check the changes. Repeatedly, this talk was asked for.
Personally, have advocated a (some) move to use Module:Infobox before, but other editors here had objections so that should have been fleshed out first and foremost. Next to this, we were not invited to look for the testcases, (current {{Chembox}} has some 17 testpages [18]). Article-changing changes (text changes, link changes, redesign of parts, layout and style changes): not even mentioned. The roll-out to 79 articles was done without announcement and of course without consensus (really, this is how you test in mainspace: open editmode, make the changes, then Preview for errors and leave without saving). There was no rollout-plan. The idea to "remove subtemplates" may be OK, but is not a convincing argument (new, more confusing and complicated subtemplates are invoked; the nine Section ones are kept; the big set of subtemplates is not a bottleneck at all but a feature—I say this having maintained them for 6 years, -- how contradicting).
All these omissions leaves us editors, you and me included, to go search for ourselves: "What is happening?". Even then, when one would raise a discovered issue here at this talkpage, chances are that the handling by the developers would be more of the same: avoidance (for example, check my requests to open discussions here). Under this sky, I myself do not feel invited to spend time on improvements. -DePiep (talk) 11:06, 4 January 2019 (UTC)
So, you have only problems with the process, and no problems with the new template itself. At the top of this section you can see the improvements the new template has. I see the subtemplates as a bottleneck, and one of the reasons that the template only had one maintainer. The 100s of sub-templates make it really difficult to figure out where "the problem is", or where to change something. I think you know why he dooes not answer your request. Christian75 (talk) 00:08, 5 January 2019 (UTC)
Yes I do have problems with the "the template itself". The "Template" (template-module-set you mean?) is not tested, discussed, proposed, etcetera. IOW: the current proposal {{Infobox chemical}} has no consensus. -DePiep (talk) 00:24, 5 January 2019 (UTC)
Oh, and almost forgot to repeat this Q: What changes are proposed? -DePiep (talk) 00:51, 5 January 2019 (UTC)
OK, I may sound too cynical. My core question is: why did not the editors convince us (us talkpagers here) that this was a good idea? If it was that good, why not? -DePiep (talk) 01:09, 5 January 2019 (UTC)

Apologies for the delay in responding -- I was on Wikibreak. Back in late November, Zackmann08 asked me to help him debug and polish {{Infobox chemical}}. I spent a few hours to expand the test cases at Template:Infobox chemical/testcases and Template:Infobox chemical/testcases2 and to fix bugs that I found in those test cases. Because Zackmann did 95% of the work on the template, I thought it would be best if he tried to convince the community to adopt it. This didn't seem to go well. Due to the negative reaction to Zackmann's actions, Zackmann has decided to disengage and not be a proponent of the new template.

I'm not a member of WP:WikiProject Chemicals and I haven't worked on WP articles about molecules. Thus, I don't feel like I can be a strong proponent of the changeover. If one or more editors in the Chemicals community (Christian75?) decided that moving over to {{Infobox}} is a good idea, I would defer to those editors to be the main proponent(s), and would be happy to provide more technical assistance.

Of course, everyone is welcome to work on the template and test cases for {{Infobox chemical}} --- I certainly feel no ownership of the template. Feel free to ping me for any questions. —hike395 (talk) 01:43, 7 January 2019 (UTC)

Heat of vaporization, liquification and sublimation needed

In section Chembox Thermochemistry. Need entries for heat of vaporization, liquification and sublimation.
Enthalpy of vaporization https://wiki.riteme.site/wiki/Enthalpy_of_vaporization
Enthalpy of fusion https://wiki.riteme.site/wiki/Enthalpy_of_fusion
Enthalpy of sublimation https://wiki.riteme.site/wiki/Enthalpy_of_sublimation
2A02:A03F:5C6C:C600:549F:9D4B:4B9D:AF67 (talk) 22:40, 23 December 2018 (UTC)

OK. Please keep helping, to get this right. We have section Chembox_Thermochemistry (with examples). I'm not a chemist, so please describe: which rows should we add? Are you sure your links are not in there already? -DePiep (talk) 22:54, 23 December 2018 (UTC)
They are not there already. I expect that "Enthalpy of fusion" will be the energy per mol or kilogram needed to melt the substance at atmospheric pressure and at its melting point (not 25°C). Enthalpy of vaporization could be measured at any temperatures where the substance is a liquid, and may be at 25° or its boiling point. Enthalpy of sublimation won't be measured for so many things but is relevant at a sublimation point. We can expect that a unit will have to be added to the number in the parameter. Graeme Bartlett (talk) 22:23, 7 January 2019 (UTC)
for carbon monoxide from the data page we have Std enthalpy change of sublimation, ΔsubHo=8 kJ/mol (at 51-68 K). So as well as a unit we may need qualification perhaps as a _Comment addition to the parameter. ; From the web[19] Latent Heat of Evaporation at boiling point (=Enthalpy of vaporization) 92.8 Btu/lb or 216000 J/kg. Latent Heat of Fusion 12.8 Btu/lb. However let us state that the unit Btu/lb is not permitted. Graeme Bartlett (talk) 22:33, 7 January 2019 (UTC)
  • OK, let's gather the core data. The table is to be improved & completed (running edits). Graeme Bartlett.
Three new data rows (demo: /testcases6#Thermo, includes existing ones)
data Enthalpy of fusion Enthalpy of vaporization Enthalpy of sublimation note
Label in {{Chembox}} (bold) Enth of fusion Enth of vaporization Enth of sublimation +quantity symbol in label
Quantity symbol (descr) ∆Hfus ∆Hvap ∆Hsublim
Unit expected kJ/g (cal/g depr) J/g, J/mol kJ/mol, kJ/kg per SI: in heat use J not cal
T, P ?
(STP={{Chembox}} default) 		1 atm, m.p. when liquid (so by definition not by circumstance right?) sublimation point. (STP by default or else add note) when defined non-STP/STP situation: is/can be in the sub/sup-scripts for quantity symbol (in LH label). The superscript in symbol ΔfHo298 signals: "not STP".
also possible in by definition not set (S)TP: phase.
Descriptive (toolbox) Latent Heat of Fusion Latent Heat of Evaporation at boiling point Latent Heat of Sublimation at sublimation point
Example CO: 12.8 J/kg CO: 216000 J/kg CO: 8 kJ/mol (at 51-68 K)
parameter name |DeltaHfus= |DeltaHvap= |DeltaHsublim=
Wikidata QID enthalpy of fusion (Q484790) enthalpy of vaporization (Q483538) enthalpy of sublimation (Q477945) (no "PID property-of-QID" PID found)
I'd like to see an other example site. A chemical site using non-SI units may be eh older.

-DePiep (talk) 19:17, 10 January 2019 (UTC)

The page testcases has demos now. -DePiep (talk) 11:12, 11 January 2019 (UTC)
Graeme Bartlett, please take one more good look at the testcases. (One request from me: please check if the ordering is right?). If everything looks OK, I'll put this new set live. -DePiep (talk) 21:07, 29 January 2019 (UTC)
The test cases look OK, description in box OK, link OK, order OK. (It wasn't me that originally asked for this, it was 2A02:A03F:5C6C:C600:549F:9D4B:4B9D:AF67|2A02:A03F:5C6C:C600:549F:9D4B:4B9D:AF67. Graeme Bartlett (talk) 02:00, 30 January 2019 (UTC)

Template-protected edit request on 30 January 2019

Please replace all code from Template:Chembox Thermochemistry with the sandbox code (Template:Chembox Thermochemistry/sandbox) (diff).

Change: added 3 new parameters per request. Added three synonym parameters to keep existing names more distinct. Refined formatting.
Discussed, consensus: #Heat of vaporization, liquification and sublimation needed above.
Tested: Template:Chembox/testcases6#Thermo. DePiep (talk) 08:54, 30 January 2019 (UTC)
 Done Please update the documentation. Cabayi (talk) 09:36, 30 January 2019 (UTC)

Template-protected edit request on 12 February 2019

Please copy all code from Template:Chembox Properties/sandbox into Template:Chembox Properties (sandbox into live template; diff)

Change: rm unused |catname=; molar mass calculation now uses |Formula_Charge= per this talk:Chem_molar_mass#.... DePiep (talk) 08:00, 12 February 2019 (UTC)

 Done -- /Alex/21 14:59, 12 February 2019 (UTC)
@DePiep: - Chemical formulas with a +1 (or -1) charge are not written C20H18NO4+1 but C20H18NO4+. Saw it at Berberine. I.e. this edit introduced a failure. Christian75 (talk) 17:51, 13 February 2019 (UTC)
Will improve the template re this. "failure" means "non-fatal error" in this case. -DePiep (talk) 17:56, 13 February 2019 (UTC)

Add MetaCyc identifier in the list of Identifiers for Compounds

We would like to add MetaCyc identifier in the list of Identifiers for Compounds. MetaCyc is highly curated database. The links to MetaCyc already exist from the EC numbers for example:https://wiki.riteme.site/wiki/Pyridoxal_oxidase. How can I add these links? — Preceding unsigned comment added by Anko04 (talk • contribs) 18:33, 5 November 2018 (UTC)

What would be the addition, information-wise spoken? MetaCyc does not have much secondary sources, so ity might be up for deletion (like we had for 3DMet recently). Also, who is "we"? -DePiep (talk) 18:47, 5 November 2018 (UTC)

Hi, "we" are the group that created MetaCyc and continues its curation on an ongoing basis - the Bioinformatics Research Group at SRI International. We believe that adding these links to MetaCyc compound pages will be very beneficial to Wikipedia users. Unlike many other compound databases (e.g. ChEBI), MetaCyc compound pages, in addition to the usual details, also contain all of the biochemical reactions that the compounds are known to participate in. For example, if you go to the L-tryptophan page (https://biocyc.org/compound?orgid=META&id=TRP#tab=showAll) and scroll down, you will see many dozens of reactions in which L-tryptophan participates. Those reactions are hyper link, so it only takes one more click to see a full diagram of the balanced reaction, including atom mapping between the reactants and products. To the right of each reaction, if applicable, is a hyperlink to a pathway in which the reaction participates. If you scroll even further down, you will find a list of all the enzymes of which L-tryptophan is known to be an effector (e.g. an inhibitor), followed by the relevant references. In short, we really think that linking to compounds in MetaCyc will provide a lot of additional information that is not easily obtained otherwise. Rcaspi (talk) 21:52, 5 November 2018 (UTC)

I find the question still appropriate, but first a bit unfriendly necessary notice. I must note possible COI's wrt the MetaCyc topic. Rcaspi, Pkarp11, Anko04 are notified on their talkpage. This may sound unwelcoming, but as WP:DISCLOSE describes this is for encyclopedial integrity, not distrust. I note that you are open about this relationship with MetaCyc. -DePiep (talk) 07:00, 6 November 2018 (UTC)
Some considerations. We have Category:Biological databases (357), Category:Chemical databases (49) articles in WP. Also, outside ar hundreds (thousands?) more. We can and should not add all these as external links, let alone in the infobox (in top) that {{Chembox}} is. We are not a linkfarm, not a directory, not an indiscriminate list of info. I am not claiming here that MetaCyc is one of those, but we must check inclusion of MetaCyc data it against these standards (as with other external links). Also, it is/would be an external link, not information or a source for article body text information. That requires more additional value to be included.
Similarities 3DMet: recently, we have removed the article 3DMet for lack of notability (discussion here), but somehow not its external link in {{Chembox}} (discussion here). I am still not convinced that link should be kept, and similar reasoning could apply here.
It is up to the WP:CHEMISTRY, WP:WikiProject Biology-related WikiProjects, ... community here to flesh out this criteria.
Wikidata has the property:

About Wikidata: meanwhile, one could consider adding the property to Wikidata (MetaCyc (Q692423)) as MetaCyc ID (3DMet ID example added in the box here). This is an independent route (independent of {{Chembox}} including), and might be more appropriate for automated mass editing, maintenance and publishing (for example, in the future a Wikidata-generated external link list could be included in compound articles).

Tech questions: which identifier does a compound have, and is there a URL-formatting line to get to a compond's item page (API)? -DePiep (talk) 07:28, 6 November 2018 (UTC)
Found the API introduction. Relates to BioCyc and EcoCyc. -DePiep (talk) 07:35, 6 November 2018 (UTC)
LOL Asking for directions: Q: How to get the object ID to link to?" A: "The easiest way to get the object ID is to just go to the the web page that you want to link to and copy the URL from there". -DePiep (talk) 17:21, 6 November 2018 (UTC)
More on tech: link (below) is dead, maybe [20]. I also would like to learn what is the relationship between BioCyc, EcoCyc and MetaCyc. Especially why we should add a MetaCyc ID link, but not the others. (I'd expect to use the most general database). BTW, the link is dead but maybe biocyc homepage is an entrance. It looks like there are two identifiers: for example L-tryptophan has "META" and "TRP". -DePiep (talk) 08:15, 11 November 2018 (UTC)

Let me try and address the concerns that you have raised. First, concerning COI: as you pointed out, we do not try to hide who we are. We believe that adding these links will be useful for Wikipedia users, and to the best of our understanding there isn't an ethical problem that should prevent us from initiating this process.

Regarding why add links to MetaCyc and not to the hundereds of other chemical databases: note that MetaCyc is somewhat unique in being not just a chemical compound database, but also a reaction and metabolic pathway database. Thus it provides a lot of additional yet relevant information for chemical compounds compared with a plain chemical compound database, even if the latter is an excellent resource such as ChEBI. The only similar resource available to my knowledge is KEGG, which by the way is included in Chembox. Yet, KEGG does not have the visual clarity that exists in MetaCyc (color-coded fully balanced reactions with the full structures of the compounds, including atom mapping), and KEGG contains less reactions that MetaCyc. So I repeat my initial motivation - links to MetaCyc will indeed enrich the data content available to Wikipedia users, in ways none of the other hundreds (or thousands) of chemical databases can provide.

I would also point out that MetaCyc has been around for a very long time (started in 1998) and has become a very well known and heavily used resource. In the discussion about 3DMet I find "The journal article introducing 3DMet has only 10 citations on Google Scholar and 4 on Web of Science, compared to 1,015 GS citations and 683 by the publisher's database for the journal article introducing PubChem." The articles describing MetaCyc have been cited over 2500 times, far more than PubChem (I can provide the list if required). Besides, important databases such as ChEBI, ExplorEnz (the Enzyme Commission database) and Uniprot already link to MetaCyc.

Regarding your tech question: To ensure the link is live, I will an example: the URL for compound with id "TRP" is [21]. As for how to get the IDs - I can see why you are laughing at the comment from the web page, but keep in mind that this was meant for people who want to link to just a few items, and do not want to spend time figuring out how to do it systematically. There are several ways to get the MetaCyc compound IDs. One way is to download a SmartTable of all compounds from MetaCyc, which would include the compound name, its MetaCyc ID and any other fields you may specify, such as IDs in other databases. There is also a metabolite translation service at https://metacyc.org/metabolite-translation-service.shtml where one can submit a list of compounds using names, IDs in other databases etc and get the MetaCyc ID back. When it comes to that, we should be able to help with the mapping. Rcaspi (talk) 18:45, 6 November 2018 (UTC)

More tech remarks above. -DePiep (talk) 08:15, 11 November 2018 (UTC)

More answers: I know all these Cyc's can be confusing, so here is an explanation. MetaCyc is a general database of metabolism from all organisms. It has by far the most compounds/reactions/metabolic pathways, as those are assembled from published information gathered from bacteria, archaea, fungi, plants, and animals. MetaCyc is used by the Pathway Tools software to infer the metabolic network of organisms with a sequenced genome, generating a specific Pathway/Genome Database (PGDB) for each one. The collection of the (currently more than 14,000) PGDBs is named BioCyc. So each BioCyc PGDB has only a subset of the compounds, reactions, and pathways that are found in MetaCyc, which is relevant for the specific organism (but in addition has the genomic information of that organism, something MetaCyc does not have). Thus, it makes sense to link chemical compounds only to MetaCyc, because it has the richest collection of this data. EcoCyc is just one of the 14,000 PGDBs in BioCyc, for E. coli K12. It stands out because it is arguably the best-curated database for any organism, having been manually curated for many years by many curators. Rcaspi (talk) 21:25, 21 November 2018 (UTC)

I ask all WikiProject participants to judge this request: does adding the external link to MetaCyc (or BioCyc, EcoCyc) add relevant information? -DePiep (talk) 08:26, 11 November 2018 (UTC)
Content arguments are in paragraph "Regarding why add links to MetaCyc ...". -DePiep (talk) 08:32, 11 November 2018 (UTC)
(do not archive yet) -DePiep (talk) 21:23, 4 January 2019 (UTC)

I am a computational biologist who is a frequent user of MetaCyc, but I am not affiliated with, nor do I have any financial interest in SRI International, the company that created and maintains MetaCyc. As previously mentioned, MetaCyc is a highly cited resource for open access curated biochemistry data. The biochemical knowledge contained in MetaCyc is manually curated from the scientific literature to describe all known associated biochemical reactions, pathways and regulatory effects. I believe it would benefit the wikipedia community to adopt a MetaCyc Compound ID property in the Chembox, so that people like me can link wikipedia chemistry pages to the valuable scientific knowledge about each chemical entity contained therein. JeremyZucker (talk) 19:40, 30 January 2019 (UTC)

(pls do not archive for now) -DePiep (talk) 08:22, 21 April 2019 (UTC)

ChemConnector Returning to Wikipedia after a hiatus - Chemistry Curation AGAIN and suggestion to add DTXSID to ChemBoxes.

I am Antony Williams. I have posted regarding my return to working on Wikipedia chemistry curation after a hiatus. I was the original founder of ChemSpider and spent a lot of time working on Chemistry curation and then left RSC (where ChemSPider was housed) to join the US-EPA. For the past four years I have been working on the EPA's CompTox Dashboard. I would like to suggest the DTXSID as a useful identifier (and linkout) from ChemBoxes and DrugBoxes because of the amount of curation work we do on chemistry data (but perfection remains difficult!). The DTXSID is already approved on WikiData. I recognize there is a potential COI. I am interested specifically in providing correct SMILES, InChIStrings, InChIKeys, data checking etc. I have posted a PARTIAL list of curation in progress here for review.

I would very much like to connect with people interested in working on a ChemBox/DrugBox validation project. ChemConnector (talk) 03:25, 21 April 2019 (UTC)

I don't see an issue re WP:COI, given that it is openly announced here and that the contribution is verifiable/reliable. Once its relevance is accepted in enwiki (community decision), the factual data looks neutral to me (either a correct or an incorrect ID, not an opinion or promotion).
We have many many ID's that can be added. (See #MetaCyc above, for example; (MetaCyc (Q692423), P?).
I support: adding this one to infoboxes Chembox, Drugbox, unless an absolute blocking argument is provided.
And: use the wikidata link (not local parameter entering at all), adding the "edit WD pencil" as we have in Vitamin C for E number and ECHA InfoCard external link IDs.
In the long run (this year?), we could consider moving all the external IDs & links to a separate box, out of the infobox. That would #1 remove minor data from the infobox and #2 allow each and every ID to be added (forgetting a relevance check) and #3 improve WP:infobox into main data only. Candidates: Category:Chemical databases (49), Category:Biological databases (357).
So I support adding this ID. Be done as a wikidata link only (no local parameter input) from day 1. -DePiep (talk) 08:29, 21 April 2019 (UTC)
  • I support adding the identifiers, but keeping the option of overwriting with local data. The last infobox RfC did show that all data should be locally controllable. I see the potential for WikiData, but their data is unreliable and their vandal/spam fighting capabilities are way below par, and we cannot expect editors from here to go repair data on WikiData (some, especially newbies, don't even know where to find it). --Dirk Beetstra T C 08:36, 21 April 2019 (UTC)
OK Dirk Beetstra, local override possible (and option |DSSTOX ID=none to suppress). What about starting a "Chem datasheet" box for major & minor data, to be put down in the article? -DePiep (talk) 08:52, 21 April 2019 (UTC)
  • @DePiep: you mean like what was done for drugbox? Not sure if I agree with that one, but on the other hand I see that the identifiers part tends to become too long. Worth an RfC on WT:CHEM I presume to see what our community thinks of that. --Dirk Beetstra T C 10:49, 21 April 2019 (UTC)
    I am thinking of a module/template say {{Datasheet chem}} that lists ~all data in a section ==Datasheet== (I've mentioned this before). In there can be all data, unloading the Infobox, leaving only main data in the infobox like b.p./m.p. and formula and structure image. The datasheet box can have unlimited external links, entropies, dipolar moment, detailed data, the current data page info, etc. It can pull data out of Wikidata, and be overwriteable by local parameters. It is everything but not an WP:infobox ;-). Sure this should be proposed at WT:CHEM. -DePiep (talk) 11:00, 21 April 2019 (UTC)
  • We need an article for EPA's CompTox Dashboard or DSSTOX. -DePiep (talk) 09:27, 21 April 2019 (UTC)
    I can work on an article for the CompTox Dashboard but would that be a COI?ChemConnector (talk) 12:42, 21 April 2019 (UTC)
I have created CompTox Chemistry Dashboard. Don't know if COI matters here, I cannot judge. -DePiep (talk) 13:15, 21 April 2019 (UTC)
@ChemConnector: clearly declare your COI, preferably both on your user talkpage and on the talkpage of the page you edit. From then you can edit the page, but refrain from anything that looks 'promotional', and step back as soon as there is someone giving comments, or reverts you (and engage in discussion with that person). Having a COI does not forbid you to edit (in the end, everyone has a conflict of interest in some area, and generally that person is a bit of an expert in that area), it just urges to take (extreme) care. If in doubt for anything you'd like to add, take it to talk and (strictly) let someone else add it for you. --Dirk Beetstra T C 13:50, 21 April 2019 (UTC)
@ChemConnector: another option is to write the whole article in draft namespace (Draft:CompTox Chemistry Dashboard), and let someone from the Articles for Creation squad check it and move (or history merge) it for you to mainspace. --Dirk Beetstra T C 13:52, 21 April 2019 (UTC)
@Beetstra: I have set up https://wiki.riteme.site/wiki/Draft:CompTox_Chemicals_Dashboard based on your suggestion. I would prefer that https://wiki.riteme.site/wiki/CompTox_Chemistry_Dashboard be deleted for now before an editor deletes it and until the draft is completed. Can you or DePiep remove it? I am cautious of COI. Thank you. I am also wondering whether you have any thoughts regarding who might be interested in taking on the curation with me? I need some data mined out of ChemBoxes to crosscheck and validateChemConnector (talk) 14:47, 21 April 2019 (UTC)
We can keep the article there, and when your drafdt is OK just overwrite it? (request move draft over existing page because of edit attributoins). -DePiep (talk) 14:52, 21 April 2019 (UTC)
Done deal. I will work on it this week and if the draft is ok'd then it can be moved over. Please note the article title WILL need to be changed as the name changed from Chemistry Dashboard to Chemicals Dashboard after the initial publication. Thanks for the advice. ChemConnector (talk) 14:55, 21 April 2019 (UTC)
In that case, just move the draft to that new name (and redirect the wrong one). -DePiep (talk) 15:09, 21 April 2019 (UTC)
I will move CompTox Chemistry Dashboard to CompTox Chemicals Dashboard (just done, actually), and then when the draft is moved there, it should be history merged to correctly preserve attributions. --Dirk Beetstra T C 08:58, 22 April 2019 (UTC)
Given that the new article is edited too, wouldn't it be better to edit that one directly? Draft:CompTox Chemicals Dashboard is not that relevant any more. ChemConnector can declare their possible COI on the talkpage, and edit (with care as was described above). -DePiep (talk) 11:45, 22 April 2019 (UTC)

In Chembox

This page tracks the Wikidata property:

I have added |DTXSID= to a {{Chembox/sandbox}}. Parameters in section {{Chembox Identifiers}}: 

| DTXSID  =
| DTXSID1 =
| DTXSID2 =
| DTXSID3 =
| DTXSID4 =
| DTXSID5 =
| DTXSIDOther =
Wikidata
By default, |DTXSID= shows the Wikidata property value DSSTox substance ID (P3117) (linked) of the article, when exists.
When entered |DTXSID=DTXSID1234567, that value will be used.
Setting |DTXSID=none will suppress the wikidata value (no show).
Indexed |DTXSID1 ... DTXSID5= will show & link as entered (no Wikidata in there).

How to test: In any Chembox article, add /sandbox to the ID section like this. Do not save, just Preview the page. The Wikidata value should show.

{{Infobox drug}} to follow.

Beetstra, I am going offline now. If you think it is OK, you can put that /sandbox live so ChemConnector can check & work ahead. -DePiep (talk) 15:21, 21 April 2019 (UTC)

ping ChemConnector. -DePiep (talk) 15:28, 21 April 2019 (UTC)
What a difference a day makes. The sandbox page looks great for Ammonia. So what do I need to do from my side to get the links in place? In I understand it it is to get the mappings between Wikipedia articles, Wikidata and DTXSIDs in place. Is that correct? If so then I will work with Egonw to update the list of mappings I have managed to pull together to get them registered onto Wikidata. When the code is pushed live for the ChemBox and Infobox drug then the linkouts would show up automatically. Am I correct? Thanks for all of the help.ChemConnector (talk) 02:16, 22 April 2019 (UTC)
The sandbox version will be put live (see request below). Then all Chemboxes will automatically show the DTXSID link (when ID is in Wikidata). So no job for you in this. I will work on {{Infobox drug}}.
With all this, there is a drawback: some articles with chembox describe multiple compounds. (This is where we use the indexes): Category:Chemical articles with multiple CAS registry numbers (1,417). In such an article not all compounds have a DTXSIDn read, or possibly read wrong (article title has different meaning in Wikidata?). I have met this situation for CAS RN's in chemical elements with allotropes, like Phosphorus vs. d:Q674; those CAS RN's were checked and added manually. In the future, one might be able to add a QID for each compound (-index) to {{Chembox}} so its Wikidata data can be pulled for all indexes.
I do not exactly understand what curation steps you have in mind. For automated or manual mass checking (say when you have a list mapping CASRN <-> DTXSID from the CompTox database), working in Wikidata itself might be easier, smart queries or updates are possible there. You could drop a question in d:Wikidata:Project_chat or in a special subpage (topical subpage). -DePiep (talk) 08:40, 22 April 2019 (UTC)
 Done live now. -DePiep (talk) 21:24, 22 April 2019 (UTC)
This is excellent thank you. Everything looks good from my side. In order to add new links all data will need to be updated in Wikidata as I understand it yes? I will coordinate with egonw for that.ChemConnector (talk) 03:10, 29 April 2019 (UTC)
Yes, I hope you find editing in Wikidata best & easiest. You can also edit at enwiki using local parameter, overwriting wikidata at enwiki. -DePiep (talk) 05:48, 29 April 2019 (UTC)

In Infobox drug

 Done live now. -DePiep (talk) 21:24, 22 April 2019 (UTC)

Template-protected edit request on 22 April 2019

Please copy/paste all code from {{Chembox Identifiers/sandbox}} into {{Chembox Identifiers}} (diff).

Change: add indexed parameters |DTXSID= creating an external link to CompTox Chemistry Dashboard. By default, the value is read from Wikidata; this is overwriteable.

Discussed here. Tested here. DePiep (talk) 08:05, 22 April 2019 (UTC)

 Done. --Dirk Beetstra T C 13:38, 22 April 2019 (UTC)

Documentation example for Pka and following are misaligned

pka is listed on the meltingpoint_somethingorother line, and the following 4 lines look wrong. Riventree (talk) 18:46, 1 May 2019 (UTC)

Template-protected edit request on 24 September 2019

Change the text “Except where otherwise noted, data are given“ to “Except where otherwise noted, data is given”

“Data are given” isn’t grammatically correct.

I’m sorry if this has already been asked, I didn’t see anything in the talk page or revision history. EmptySora (talk) 04:16, 24 September 2019 (UTC)

 Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. See Data#Etymology and terminology. As that section notes, the word data is reasonably considered plural (vs datum as singular) in science contexts. I just checked ACS Style Guide, and it concurs. DMacks (talk) 04:54, 24 September 2019 (UTC)

Indexing EC_number, RTECS, 3DMet

@Graeme Bartlett, DMacks, and Beetstra: From this discussion (May 2018): proposal to add indexes to parameters |EC_number, RTECS, 3DMet=. I have prepared the Chembox sandboxes for these. See testcases for #EC_number_indexed, #RTECS_indexed, #3DMet_indexed.

When everything looks stable, I'll prepare for going live (remove /sandbox test code &tc). -DePiep (talk) 12:27, 30 September 2019 (UTC)

Thanks, I thought this fell into a black hole or something. Can we also have StdInChi and StdInChiKey indexed like InChi is? Graeme Bartlett (talk) 12:45, 30 September 2019 (UTC)
The sandbox test of the sandbox templates looks OK for indexing EC_number RTECS and 3DMet. Graeme Bartlett (talk) 12:52, 30 September 2019 (UTC)
checkY Prepared for going live. Testcases invalid. -DePiep (talk) 11:11, 1 October 2019 (UTC)
I note that |EINECS= is a synonym for |EN_number=, but not indexed (|EINICS1, EINECS2, ...= do not exist). -DePiep (talk) 16:33, 1 October 2019 (UTC)

Indexing StdInChI like InChI?

Can we also have StdInChI and StdInChIKey indexed like InChI is? Graeme Bartlett (talk) 12:45, 30 September 2019 (UTC)
I remember long time ago I discussed this with Beetrstra (could be re {{Drugbox}}). The point was IIRC: why list multiple InChI's for a compound, one of them *not* being the standard InChI? Wouldn't it be better to only use the standard one (as editors guidance)? -DePiep (talk) 13:02, 30 September 2019 (UTC)
So if we add a standard InChI should we remove the InChI parameter? I see no use in having both together. Anyway the request to index stdinchi still stands.Graeme Bartlett (talk) 01:30, 2 October 2019 (UTC)
In anthrol, I have fixed usage of |StdInChI1, 2, 3= into |InChI1, 2, 3= etc [22] because these Std's do not show (not a parameter). -DePiep (talk) 08:38, 3 October 2019 (UTC)
The question is: why have a separate |StdInChI= at all, next to |InChI=? (Same for the key). Why would we add two InChI's for one compound, one of them not being the /S standard? How and why would we have a separate notation for the /S standard?
Consider, proposal: 1. deprecate and remove |StdInChI= use |InChI= instead. 2. When two InChI's are present, only use the /S standard one. 3. Maintenance: write in the documentation that we only need the /S one. (Same for their keys). -DePiep (talk) 08:44, 3 October 2019 (UTC)
  • This proposal part 1,2,3 sounds good to me. In addition we will also have a background task to remove redundancy (perhaps checking that the two inchis are the same) and to rename stdinchi to inchi. Docco should state that /S stdinchi form is preferred and allowed for inchi= parameter. Perhaps we have to notify the project members of the change. There could be a warning in preview mode. Graeme Bartlett (talk) 11:21, 3 October 2019 (UTC)
All fine, yes the background maintenance task is good. One objection could be: a non-standard InChI should still be a search hit (from outside/inside wiki), and so be present? -DePiep (talk) 11:27, 3 October 2019 (UTC)
+Same or similar for {{Infobox drug}}, only has |StdInChI= names. Tech note: also, we must keep in mind that User:CheMoBot does verification on Std's, using {{Stdinchicite}} internally. -DePiep (talk) 12:26, 3 October 2019 (UTC)

Template-protected edit request on 1 October 2019

Please copy/paste all /sandbox code into the live parent template (4 ×):

Changes: indexing more parameters; discussed & consensus: #Indexing EC_number, RTECS, 3DMet. Testcases are now defunct. -DePiep (talk) 11:22, 1 October 2019 (UTC) DePiep (talk) 11:22, 1 October 2019 (UTC)

 Done Sceptre (talk) 16:12, 1 October 2019 (UTC)

GHSSignalWord

The parameter GHSSignalWord should only accept the two possible signal words, i.e. Danger and Warning. --Leyo 21:13, 22 October 2019 (UTC)

Will adjust this. -DePiep (talk) 05:57, 23 October 2019 (UTC)
If it is "Danger", should the colour be red? Occasionally I have seen people deliberately add some colour formatting. But it could be automatic. Graeme Bartlett (talk) 06:19, 23 October 2019 (UTC)
See monthly param check on usage of |GHSSignalWord=. Formatting will be stadardized of course. Does GHS deeinition say anything? (Btw, if it is actually "word", we do not have to add warning effects like red IMO). -DePiep (talk) 06:30, 23 October 2019 (UTC)
[23] (rev 08 = 2019) -DePiep (talk) 15:53, 23 October 2019 (UTC)
The English pdf says on p. 35/570:

1.4.10.5.2 Information required on a GHS label
(a) Signal wordsA signal word means a word used to indicate the relative level of severity of hazard and alert the reader to a potential hazard on the label. The signal words used in the GHS are “Danger” and “Warning”. “Danger” is mostly used for the more severe hazard categories (i.e. in the main for hazard categories 1 and 2), while “Warning” is mostly used for the less severe. The tables in the individual chapters for each hazard class detail the signal words that have been assigned to each of the hazard categories of the GHS.

i.e., no bolding, uppercase first only. Looks like we should use this form too, and no extra formatting. (After all, we are only giving the information, no need to give an actual signal). -DePiep (talk) 16:02, 23 October 2019 (UTC)
Bolding looks OK. See proposal below.-DePiep (talk) 17:58, 23 October 2019 (UTC)
I think not. I've never seen it used that way on actual labels, chemicals either have a signal word or they don't. --Project Osprey (talk) 12:01, 23 October 2019 (UTC)
I agree. --Leyo 20:14, 24 October 2019 (UTC)

Proposal

Prepared in sandbox. Documentation will look like this:

GHS Signal word – demo
Hazards
GHS labelling:
Danger[1]
|GHSSignalWord= can have input |GHSSignalWord=DANGER or |GHSSignalWord=WARNING (A=a).
The infobox will show the Signal word pre-formatted.
A reference can be added too: |GHSSignalWord=Danger<ref>{{cite book|title=Hello world}}</ref>.
GHS Signal word – err demo
Hazards
GHS labelling:
FooBar [→Category:GHS errors]
Any other word will result in an error (message in preview, Category:GHS errors listing when in mainspace). Example: |GHSSignalWord=FooBar

See /testcases10. FYI, formatting in input is neglected too, so |GHSSignalWord='''DANGER''' will resolve as expected.

Comments? @Leyo, Graeme Bartlett, and Project Osprey:. -DePiep (talk) 18:19, 23 October 2019 (UTC)

References

  1. ^ Hello world.
It looks like lower case works. Adding spacing around the word works. So looking also at the test cases I am happy with this. Graeme Bartlett (talk) 20:30, 23 October 2019 (UTC)

Template-protected edit request on 24 October 2019

Please copy/paste all sandbox code into the live templates (twice):

Change: per Talkpage proposal, the GHS Signal word can only be "Danger" or "Warning". This change checks & formats the input. Also error-checking & -categorising. Tested: /testrcases10 (now defunct because the /sandbox chain has been removed for going live).

Discussion & consensus: See #GHSSignalWord. DePiep (talk) 09:17, 24 October 2019 (UTC)

Thanks. Agree about the code, but the only way I could think of. Have you met other solutions? -DePiep (talk) 10:49, 24 October 2019 (UTC)
It was not a criticism, just an observation. The only way to do it cleanly would be to separate the value from the reference, i.e.
GHSSignalWord=Danger
GHSSignalWord_ref={{cite book|title=World greetings|author=Test}}
or even better, get a property for this added at Wikidata and keep the value and reference over there. — Martin (MSGJ · talk) 13:09, 24 October 2019 (UTC)
Sure, but I find separate parameters not editor-friendly. Wikidata could be done, but it is a long term improvement wrt chemicals. (Not read as criticIsm, I was just asking for better practices). -DePiep (talk) 15:22, 24 October 2019 (UTC)

Template-protected edit request on 24 October 2019

Oops, used wrong template code (duplicate arguments). Pls put sandbox code into {{Chembox Hazards}} (diff). -DePiep (talk) 10:57, 24 October 2019 (UTC) DePiep (talk) 10:57, 24 October 2019 (UTC)

Yes, found and fixed. All the best: Rich Farmbrough, 12:03, 24 October 2019 (UTC).

Field to indicate only partial infobox

Chembox/Archive 12
Hazards
GHS labelling:
GHS05: CorrosiveGHS06: ToxicGHS09: Environmental hazard
Danger
H314, H330, H400
P260, P273, P280, P284, P305+P351+P338, P310
NFPA 704 (fire diamond)
NFPA 704 four-colored diamondHealth 3: Short exposure could cause serious temporary or residual injury. E.g. chlorine gasFlammability 0: Will not burn. E.g. waterInstability 0: Normally stable, even under fire exposure conditions, and is not reactive with water. E.g. liquid nitrogenSpecial hazards (white): no code
3
0
0

We have over a hundred cases where {{chembox}} is used with only a single section, in order to include a collection of a certain type of data in an article section rather than as a complete infobox at the top of a page. These uses populate various Category:Chembox tracking categories because they don't have some of the main fields. That's intentional...they are only used as the container for what is intentionally just one box section, so the page should not be placed in a cleanup-needed cat.

As a specific example, most element-pages have {{Chembox Hazards}} in a "Biological role and precautions" section, which places the page in Category:Chembox articles without image. But the image instead goes in {{Infobox element}}. So that cleanup-cat gets cluttered with many articles we know aren't actually in need of attention. Should {{Chembox}} have a |container_only=y flag to indcate this use, which would inhibit the tracking that isn't applicable to this use-case? DMacks (talk) 03:58, 4 June 2020 (UTC)

DMacks, never noticed that. Good idea. Dirk Beetstra T C 05:58, 4 June 2020 (UTC)
I get the idea. But, in the example, this would also prevent tracking of {{Chembox Hazards}} parameters. -DePiep (talk) 06:19, 4 June 2020 (UTC)
@DePiep: not necessarily, if the main template has that parameter, it should only suppress the categorisations on the main template, not on the subtemplates. I've now pasted here the 'chembox' from Bromine#Biological role and toxicity. --Dirk Beetstra T C 06:49, 4 June 2020 (UTC)
{{ec}} Thanks for the example and clarification. Due to the layers of templates, each section-specific template wouldn't know about fields in the higher level. So this new tag:
{{Chembox
| show_footer = no
| container_only=y     <!-- this is the new one added to the [[bromine]] example -->
|Section7={{Chembox Hazards
| GHSPictograms = {{GHS05}}{{GHS06}}{{GHS09}}
| GHSSignalWord = Danger
| HPhrases = {{H-phrases|314|330|400}}
| PPhrases = {{P-phrases|260|273|280|284|305+351+338|310}}
 }}
}}
would not be visible within {{Chembox hazards}}, which is presumably where the parameters to that subtemplate get tracked. DMacks (talk) 07:08, 4 June 2020 (UTC)
re all: I see, only outer template {{Chembox}} itself is shut down. Not subsections like {{Chembox Hazards}}.
Note: all parameters that are in outer Chembox are listed in Template:Chembox/doc/parameter list. (Full parameter overview in {{Navbox Chembox}}). First glance looks like all these can be untracked without harm (pls check). Of course, those with |container_only=y should & will be tracked ;-). -DePiep (talk) 13:41, 4 June 2020 (UTC)
Thought: should this usage not involve formal "not an infobox" effects too? eg the [[Bromine#Biological role and toxicity|brominde]] example. -DePiep (talk) 18:32, 4 June 2020 (UTC)
What effects are those? DMacks (talk) 21:15, 5 June 2020 (UTC)
Effects are less visually, more principaly (info semantics). "Infobox" is article summary (information-wise, a high & useful aim!). But a container_only Hazards list is not that (while OK by itself).
In general about infobox and {{Chembox}}: I think Chembox is overloaded (too much data for an infobox). External links could/should be elsewhere IMO.
I will show & ask sandbox proposals here. -DePiep (talk) 23:14, 5 June 2020 (UTC)
Sounds good. I just realized another reason to avoid having these stubs be considered as "infobox"...it would confuse searches for chemical articles that are missing infoboxes. DMacks (talk) 03:26, 7 June 2020 (UTC)

Proposal

@DMacks and Beetstra: I have prepared this in the sandbox.

This happens when set |container_only=yes

  • None of these categories are checked for, full stop:
Category:Chemboxes which contain changes to verified fields
Category:Chemboxes which contain changes to watched fields
Category:Articles containing unverified chemical infoboxes
Category:Chembox articles without image
Category:Chembox image size set
Category:Chemical pages containing a local image
Category:Chemical infoboxes with style settings
Category:Chemical infoboxes with tracked parameters

Note that CheMoBot is still active in this box (checking & editing for its set of parameters watched and tracked like CAS number); but this activity re the outer template is not tracked nor categorised (| Verifiedfields= | Watchedfields= | verifiedrevid=).

  • The footer (with the message about standard state &etc) is suppressed; can made showing by |show_footer=yes.
  • The article is added to Category:Chembox container only, a tracking category.
  • Parameters entered in the outer {{Chembox}} show as usual (|Name=, images, etc).
  • Errors in the subsection (e.g. in {{Chembox Hazards}}) are tracked as usual.
You can also test in preview by editing Bromine#Biological_role_and_toxicity:
 {{Chembox/sandbox
 | container_only=yes
 ...
 }}
OK? -DePiep (talk) 09:18, 13 June 2020 (UTC)
Works as described. I don't understand the existing layers of CheMoBot tracking, so I can't comment on anything related to the watched/tracked-changes of those fields. But given that a top-level image field is still allowed, I don't think we should ignore tracking categories related to weird uses of them (image-size-set and containing-a-local-image). We simply have decided that they aren't required. DMacks (talk) 15:23, 13 June 2020 (UTC)
Yes to this ("layers of CheMoBot tracking" is good wording). This is a crude solution, I preferred not to go into tracking/bot details. Alas, Beetstra, who runs CheMoBot, might add more to this. -DePiep (talk) 19:51, 13 June 2020 (UTC)
checkY will prepare this for live. Tests may be broken for now. -DePiep (talk) 19:49, 15 June 2020 (UTC)
 Done -DePiep (talk) 09:38, 21 June 2020 (UTC)

Template-protected edit request on 20 June 2020

Please replace {{Chembox}} with {{Chembox/sandbox}}, all code (diff).

The change is: new parameter |container_only=yes suppresses tracking by upper category {{Chembox}}. Full stop.
Discussion & consensus is here. Tests are /testcases11. (could be defunct now, temp). DePiep (talk) 21:44, 20 June 2020 (UTC)
 Done — Martin (MSGJ · talk) 06:10, 21 June 2020 (UTC)
Thanks DePiep! DMacks (talk) 13:38, 21 June 2020 (UTC)

Template-protected edit request on 28 August 2020

It would be nice to have triple point information, using |TripleTP= in exactly the same way that |CriticalTP= currently works. For consistency with {{subst:Infobox element}}, it should appear immediately before the a triple point entry.

The actual edit is pretty straightforward cut & paste duplicating the existing {{Chembox CriticalTP}} and adding it in the right place to the template.

I've added the TripleTP info to Methane, so if it doesn't get deleted, that could be used as a test. 196.247.24.12 (talk) 08:32, 28 August 2020 (UTC)

 Not done: please make your requested changes to the template's sandbox first; see WP:TESTCASES. This is a rather crazy template, and while I agree with the idea of adding the triple point, it needs to be sandboxed first to make sure all of the pieces fit together properly. Primefac (talk) 01:04, 2 September 2020 (UTC)

CAS numbers

Hi, in Validation of CAS numbers; collaboration with Wikidata? I indicate that we're talking to a trusted source that can help us validate CAS RNs. For Wikidata I am thinking of a rich provenance model to annotate the links between Wikidata pages and CAS numbers. The link between chemicals on Wikipedia and Wikidata is a bit tricky, as Wikidata basically has a page for each ChemBox and because of the sitelinks, also for each Wikipedia page. That goes well, until there is more than one ChemBox on one Wikipedia page, or when a ChemBox represents more than one concept (e.g. DL, D, and L versions of the same chemical graph). But we're talking here about a few hundred thousand CAS RNs of high quality, that we want to use to validate CAS numbers on Wikipedia. I am personally hoping we can do this via a tight Wikidata/ChemBox integration. Your thoughts, please. --Egon Willighagen (talk) 08:07, 11 October 2020 (UTC)

It's a hopeless design flaw that there is a 1:1 mapping from WD entries to WP articles:( Also, major segments of WP fundamentally distrust WD content outright. You might get better acceptance if it's done on enwiki directly (rather than shifting to WD). There is already a flag here for validated data, and I'm not sure if there is a way to have a similar tracking on WD that would appear on enwiki boxes. DMacks (talk) 08:19, 11 October 2020 (UTC)
I can personally live with an outcome where Wikipedia-EN and Wikidata are done in parallel. I am aware of all the complications, but hope we can minimize the effort. --Egon Willighagen (talk) 09:08, 11 October 2020 (UTC)

Template-protected edit request on 18 October 2020

Please make these edits:

Changes
Cleanup code and remove unused code & comments
Discussed?
No, just trivial improvements, unused code cleanups and removal of comments
Tested?
To my best knowlegde, and using /testcases11#Container only, when the /sandbox stack was working (now disfunct b/c going live)
Check?
After the edits, one could check articles: Hydroxycarbamide#Chemistry, Ammonia.
DePiep (talk) 21:18, 18 October 2020 (UTC)
To editor DePiep:  done. P.I. Ellsworth  ed. put'r there 23:33, 18 October 2020 (UTC)
Thanks. Looks good. -DePiep (talk) 23:36, 18 October 2020 (UTC)

Template-protected edit request on 19 October 2020

Please replace (overwrite) all code in {{Chembox Footer}} with {{Chembox Footer/sandbox}} (diff).
Change: fixes a misplaced </div> (was outside of if-clause, causing an unbalanced /div closure)

DePiep (talk) 18:06, 19 October 2020 (UTC)

To editor DePiep:  done. P.I. Ellsworth  ed. put'r there 19:34, 19 October 2020 (UTC)

Template-protected edit request on 20 October 2020

Please reoplace all code in {{Chembox Identifiers}} with {{Chembox Identifiers/sandbox}} (diff).

Change: change regex pattern, to fire also when the 'none' is amid other input strings.

Discuss, Tested: technical improvement only, tested OK in my userspace. @DMacks: DePiep (talk) 15:54, 20 October 2020 (UTC)

To editor DePiep:  done, and thanks again! P.I. Ellsworth  ed. put'r there 17:40, 21 October 2020 (UTC)

FDA: US pregnancy category, PLLR removed

Following FDA rule changes, US pregnancy category (letters) and PLLR are removed from {{Chembox}} (section {{Chembox Pharmacology}}).

Parameters abandoned: |pregnancy_US= pregnancy_US_comment= PLLR= (ca. 12 uses in mainspace).

Prescription drugs submitted for FDA approval after June 30, 2015 will use the new format immediately, while labeling for prescription drugs approved on or after June 30, 2001 will be phased in gradually. Medications approved prior to June 29, 2001 are not subject to the PLLR rule; however, the pregnancy letter category must be removed by June 29, 2018. For generic drugs, if the labeling of a reference listed drug is updated as a result of the final rule, the abbreviated new drug application (ANDA) labeling must also be revised. Labeling for over-the-counter (OTC) medicines will not change, as OTC drug products are not affected by the new FDA pregnancy labeling.

— https://www.drugs.com/pregnancy-categories.html

See discussion at Template talk:Infobox drug § Pregnancy US parameter. -DePiep (talk) 21:55, 29 December 2020 (UTC)

Template-protected edit request on 29 December 2020

Please replace all code with all sandbox code, in these two templates:

Changes, talk and test: Template talk:Infobox drug § Pregnancy US parameter; /testcases8

-DePiep (talk) 23:02, 29 December 2020 (UTC)

To editor DePiep:  done, and thank you for your special thoughts at your previous edit request! P.I. Ellsworth  ed. put'r there 02:45, 30 December 2020 (UTC)
Yes, I'm watching you every second ;-) ;-) -DePiep (talk) 02:47, 30 December 2020 (UTC)

parameter Solvent6

NFPA 704 reading order

I recently made a change to the reading order of the underlying template. Your feedback is appreciated! Template talk:NFPA 704 diamond#Reading order. Matt Fitzpatrick (talk) 16:43, 25 February 2021 (UTC)

Matt Fitzpatrick [24]: where is "I" defined as a synonym, and how does this confusing addition help an editor? -DePiep (talk) 17:47, 25 February 2021 (UTC)

I stands for "instability", which is the word used for the yellow hazard since the 2017 standard. Using R for "instability" would be confusing if an editor didn't know it used to be called "reactivity". I wrote it so that either I or R works. Matt Fitzpatrick (talk) 17:56, 25 February 2021 (UTC)

Adding a short description

Could someone add additional code, please, to create an automatic short description, such as "Chemical compound"? That would be a great help in reducing the number of articles that are missing such a description. Pinging Trialpears: would you be able to help? MichaelMaggs (talk) 10:23, 23 March 2021 (UTC)

It would be trivial to add "Chemical compound" as the default short description for articles using this infobox. It would be overridden by manually added descriptions. I will let the request be for a day or two just to make sure that no one objects since this could conceivably be controversial. --Trialpears (talk) 11:43, 23 March 2021 (UTC)
We could add the chemical formula to the short descriotion (the empirical one = the simplest one). I note that a single infobox can contain multiple compounds (throug indexes). -DePiep (talk) 12:30, 23 March 2021 (UTC)
That would be too complex. The description needs to be kept short and non-technical to comply with WP:HOWTOSD: "avoid jargon, and use simple, readily comprehensible terms that do not require pre-existing detailed knowledge of the subject". MichaelMaggs (talk) 16:28, 23 March 2021 (UTC)
 Done, no objections. If you want it modified consensus is necessary.
FWIW, this template is used for ions too - which are not chemical compounds. (it was merged with {{ionbox}} long time ago). Christian75 (talk) 02:35, 28 March 2021 (UTC)
Hm that's true. This is only applicable for atomic ions or have I gotten my terminology mixed up? If it's only atomic ions like chloride I feel like it should be simple enough to track them all down and give them another description. --Trialpears (talk) 02:43, 28 March 2021 (UTC)
A compound must be net neutral charge and contain more than one element. So the chloride ion (Cl–) fails the definition in two different ways whereas phosphate (PO43–) and Buckminsterfullerene (C60) each fail in one unique way. We'd need to use molecular-formula data, which is in fields of the {{Chembox Properties}} sub-template, to know whether it's a compound or something else. DMacks (talk) 04:46, 28 March 2021 (UTC)
Uhm this will be more difficult then. Since the information is in a subtemplate it can't be reasonably accessed from this template. I see two possible solutions: Either move the short description into {{Chembox Properties}} and write some scribunto patterns to parse chemical formulas making sure those two criteria are met and giving the rest some other short description or look at the title of the page which should be possible to identify ions with but things like Buckminsterfullerene would be difficult that way. I will start sandboxing something and see where that takes me. --Trialpears (talk) 09:18, 28 March 2021 (UTC)
@Trialpears: Option 3?: In {{Chembox Properties}}, perform that Lua "Is compound" check, and create tracking category ("not a compound"). And add to main {{Chembox}} parameter like |Is_compound=. The SD can respond to this value (for now, only option is 'ion' or 'compound' then).
I note that the "Is compound" check you mention will also be useful when this template is formed into a regular {{Infobox}}.
There is also the situation when the infobox (-table) has multiple compounds/ions by index (in sub {{Chembox Identifiers}} ;-) ); this can have various reasons (chemical group, isomers, ...). Does the SD need to handle this too? -DePiep (talk) 11:00, 28 March 2021 (UTC)
I have to say that this not being a regular infobox is a pain. If all compounds discussed in the infobox are a chemical compound or ion I feel like it's fine to just call it a "Chemical compound" or "Ion". The problem is when it's one ion and on compound in which case I wouold probably want to leave it to the humans. The problem then is that I can't know that based on the information in {{Chembox properties}} if that is the case. Some options to solve this are probably adding a parameter to {{Chembox}}, convert everything to a infobox so I can use all information simultaneously or identifying the affected articles and dealing with the manually. The latter seems like the simpler choice and is what I'm leaning towards. This would put the description in {{Chembox properties}} but that isn't really an issue except it can look slightly weird for editors showing it with custom css. The is compound check should probably be a stand alone module since it seems likely to be useful elsewhere. --Trialpears (talk) 11:47, 28 March 2021 (UTC)
Most transclutions are from chemical compounds. We could add a parameter sd (or short_description) to the infobox for non-chemical compounds and something like {{short description|{{{short_description|Chemical compound}}}|noreplace}}. Christian75 (talk) 11:59, 28 March 2021 (UTC)
All this complexity really isn't worth adding. The point is simply to save the one-off task of adding SDs manually where there isn't one already. Coding up complicated exceptions (which may later be edited manually anyway), and especially making changes to the infobox to do it, is not a good use of anyone's time. I'd suggest leaving the automated text as "Chemical compound" and correcting that manually in the relatively few cases where eg "ion" would be better. If someone can tell me what to look for, I'll even volunteer to do it myself with AWB. MichaelMaggs (talk) 12:13, 28 March 2021 (UTC)
It will require a not insignificant amount of manual work but you're more than welcome! This search is decent but since the Category:Ions tree is far from clean it has tons of issues requiring manual checks for all, but I guess it isn't that bad since most of that can be done by taking a look at the title. --Trialpears (talk) 14:09, 28 March 2021 (UTC)
Trialpears, that doesn't look too bad, but any idea how I can get those results into a spreadsheet? MichaelMaggs (talk) 15:46, 28 March 2021 (UTC)
MichaelMaggs, AWB has the ability to use search results directly from a query. Otherwise I've placed the entire list without extra noise here. --Trialpears (talk) 15:51, 28 March 2021 (UTC)
Trialpears, that's great, thanks. MichaelMaggs (talk) 15:53, 28 March 2021 (UTC)
As a generic default, how about "chemical substance" (less technical-sounding as well). DMacks (talk) 18:57, 28 March 2021 (UTC)
DMacks, interesting idea. Do you think that works for ions as well? (ie could I skip the manual exceptions?) MichaelMaggs (talk) 20:11, 28 March 2021 (UTC)
Chemical substance is more generic (as in: "stuff we don't know about"), so might fit even ions. However, IMO this does not serve the SD goal well enough.
By the way, how close are we to the idea: 1. default = 'chemical compound', and 2. manual parameter to edit |sd= (eg =ion, =chemical group)? Could be supported by smart tracking category. -DePiep (talk) 20:34, 28 March 2021 (UTC)
So far we're at 1. default = 'chemical compound'. I'll be doing 2 semi-manually as discussed immediately above. Don't think there is benefit in adding compexity with parameters that have to be added manually when anyone can just add a new description manually instead. MichaelMaggs (talk) 21:33, 28 March 2021 (UTC)
re #2.: How to edit for a non-default then? Not a parameter-edit in {{Chembox}}?? -DePiep (talk) 21:45, 28 March 2021 (UTC)
Editing template generated descriptions with a parameter is done nowhere else and will cause significant compatability issues with short desk helper and other tools. Instead short descriptions in templates can be overridden by placing a description directly in the article. If you want to change that description its just to edit the page as usual. --Trialpears (talk) 22:00, 28 March 2021 (UTC)
OK, got it. -DePiep (talk) 22:03, 28 March 2021 (UTC)

 Done. Starting with the search that Trialpears suggested above, I've added manual short descriptions to 64 articles, overriding the infobox default "Chemical compound". Many more of course already have manual descriptions and none of those have been touched. MichaelMaggs (talk) 11:45, 29 March 2021 (UTC)

Issues with word wrapping and Template:Longitem

In Template:Chembox AllOtherNames, the values of the PIN and SystematicName parameters are wrapped in Template:Longitem, unlike IUPACName. However, the latter template's display:inline-block; prevents the word-wrap:break-word; in Template:Chembox AllOtherNames/format from functioning, making the text spill past the right end of the chembox in certain scenarios (usually involving long blocks of locants or stereodescriptors). In the example below, the 1st table directly passes the name to Template:Chembox AllOtherNames/format, while the 2nd inserts it in a Template:Longitem.

A minimal example of the issue and a possible solution.
Names
(2R,3R,4R,5R,6R,7R,8R,9R,10R,13R,14R,15R,16R,17R,18R,19R,20R)-1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20-Icosachloroicosane
Names
(2R,3R,4R,5R,6R,7R,8R,9R,10R,13R,14R,15R,16R,17R,18R,19R,20R)-1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20-Icosachloroicosane
Names
(2R,3R,4R,5R,6R,7R,8R,9R,10R,13R,14R,15R,16R,17R,18R,19R,20R)-1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20-Icosachloroicosane

I've put a possible solution in the 3rd table. It sets |style=max-width:22em; on the substitution of Template:Longitem, reiterating the value set in Template:Chembox AllOtherNames/format. This fix would be applied to Template:Chembox AllOtherNames, causing some additional work if the value is ever to be changed. LegionMammal978 (talk) 02:07, 6 April 2021 (UTC)

Fluorescence and stability

Hi there, I'm wondering if there are any Chembox sections for storing information about fluorescence and stability characteristics? E.g. for fluorescence, for something like fluorescein, it might say 494/512 em/ex (water). For stability, for something like acetyl CoA, it might say something like "Dry solids may be stored at 0 °C in a desiccator over long periods without decompisition. Generally stable in neutral and moderately acid solutions, even at elevated temp, hydrolysed in strong acid. Rapidly hydrolysed in alkaline solns. React quantitatively with neutral NH2OH forming acylhydroxamic acid."[1]Photocyte (talk) 00:02, 24 April 2021 (UTC)

  1. ^ Dawson, Rex M. C.; Elliott, Daphne C.; Elliott, William H.; Jones, Kenneth M. (2002). Data for Biochemical Research (3rd ed.). Clarendon Press. p. 117. ISBN 978-0-19-855299-4.

Template-protected edit request on 16 December 2021

Change: fix unbalanced ""-quotes, bring closing " within same #if:-clause.
-DePiep (talk) 19:04, 16 December 2021 (UTC) DePiep (talk) 19:04, 16 December 2021 (UTC)
 Done — Martin (MSGJ · talk) 19:48, 16 December 2021 (UTC)

Template-protected edit request on 16 December 2021

Change: remove parameter |data_page= Red XN. Undocumented; has 2020 comment "TODO" check; redundant to |data page pagename= Green tickY. Tested in live articles.
(Will check after: 1-Propanol uses |data page pagename= to add Supplement data page section to Chembox; Ammonia has automated data page Supplement link).
DePiep (talk) 20:03, 16 December 2021 (UTC)
 Done * Pppery * it has begun... 18:14, 18 December 2021 (UTC)

Edit request

Please, could an admin apply this small change to {{Chembox Hazards}}? Od1n (talk) 12:11, 7 October 2021 (UTC)

Technically a correct change, but trivial so maybe useless. No effect on rendered page. Wait and go with other edits? -DePiep (talk) 12:37, 7 October 2021 (UTC)
 Done User:GKFXtalk 20:37, 8 October 2021 (UTC)
Trivial edit by User:GKFX, using required TE rights. -DePiep (talk) 20:47, 8 October 2021 (UTC)

Template-protected edit request on 9 November 2021

Remove CASOther or change it to avoid the error. Also why is there a not after the systematic IUPAC name?(all of these requests are on the Medium form.) Keres🌕Luna edits! 19:09, 9 November 2021 (UTC)

Which error? Links please. -DePiep (talk) 19:26, 9 November 2021 (UTC)
 Not done: {{edit template-protected}} is usually not required for edits to the documentation or categories of templates using a documentation subpage. Use the 'edit' link at the top of the green "Template documentation" box to edit the documentation subpage.

If I've misunderstood the request and you aren't asking for an edit to the documentation, then please provide more details of what exactly you want changed. * Pppery * it has begun... 20:34, 9 November 2021 (UTC)

  • This must be one of those esoteric chem-expert edit requests. A cursory glance at the edit history seems to show that the |CASOther= parameter was never in this template, at least not for very long. It may have been tested at some point, because one testcases page, Template:Chembox/testcases3, uses the parameter in one test case under "Identifiers". There was no argument given, though. I added an argument, but since the param isn't in the template, nothing appeared, not even the sandbox version. No other testcases page uses the parameter. I was unable to find anything resembling a not after any IUPAC names on the testcases pages. OP should make the changes in the sandbox so we can see more detail, or like * Pppery * wrote, go ahead and get rid of the |CASOther= parameter on the /doc page, which probably should be done anyway. I think? Maybe? I'm no expert. P.I. Ellsworth - ed. put'r there 22:29, 9 November 2021 (UTC)
Thanks Paine Ellsworth for this report. Now I see.
CAS RN's are handled in subtemplate {{Chembox Identifiers}}; so this talkpage is OK for requests. |CASOther= is nor ever was a parameter in the {{Chembox}} set. I did not find any |CASOther=, with input, being used in Chembox articles. However, it was used in documentation. I have changed it into the correct |CASNoOther= [25]. I cannot reproduce the "not after the systematic IUPAC name?" issue mentioned in OP. -DePiep (talk) 07:48, 10 November 2021 (UTC)
Thank you for that, DePiep! I've looked and looked. Can't put this down for some reason. Looked through the OPs conts. and found a lot of edits to chem pages. Some ibox entries had the little green check after them, some had the external link symbol after them, and some had the little slanted pencil link to Wikidata after them, but I saw no "not". One guess would be that a vandal entered the word "not" in an individual ibox in an unknown article. An example would be needed before that request becomes clear. (edit conflict)I wonder, what does the OP mean by "all of these requests are on the Medium form"? Never mind. I found the word "not" in the /doc under the header Medium form and removed it. P.I. Ellsworth - ed. put'r there 18:31, 10 November 2021 (UTC)
Is why I asked for clarification. Didn't find Medium form (page?). I consider this one closed. And yes, Chembox is high tech 2008 material. I was surprised to find a Chembox article being TFA last week! -DePiep (talk) 18:41, 10 November 2021 (UTC)
Rhodocene does appear to be a great article! Note that I found the "not" on the /doc page that the OP was citing and removed it. P.I. Ellsworth - ed. put'r there 18:52, 10 November 2021 (UTC)
Thumb is up here. Nice detail with Rhodocene that the JSmol 3d interactive external link (chembox) could not use the SMILES definition string, because the Rh atom must be sandwiched—that's the whole point of it! (I had to adjust). -19:49, 10 November 2021 (UTC)
DePiep you are much better than I am at this chem stuff. In the Rhodocene ibox, what is meant by the red "x" after the CAS Number vs. the green check mark that follows the ChemSpider number? and how do they get tacked onto the ends of numbers like that? Do you know? P.I. Ellsworth - ed. put'r there 00:01, 11 November 2021 (UTC)
I am surprised that a featured article promotion will allow the red x, as it proves that no one checked the accuracy of the value and updated the cascite template. I have now done that. Graeme Bartlett (talk) 00:20, 11 November 2021 (UTC)
I get it now. I was beginning to think that the bot added the tick marks directly to the html source code bypassing the wikimarkup. It's the "ref" params that are used. That's pretty cool! P.I. Ellsworth - ed. put'r there 00:31, 11 November 2021 (UTC)
@Paine Ellsworth: the ticks/crosses are by WP:CHEMVAL/{{cascite}}: validation (tracking) of certain parameters in Chembox and Drugbox (think CAS RN). A bot tracks changes, then adds/adjusts like |CASNo_Ref={{cascite|changed|???}}. Chembox then shows a red/green sign, and categorises for maintenance. btw, I am not good in chem, but its the template's for me ;-) . -DePiep (talk) 09:30, 11 November 2021 (UTC)
Thanks DePiep for all your help on this. Looks to me like editors just sign up to work on chem evals, much like any other WikiProject or collaboration. As for the tick marks, we agree that something more is needed. Perhaps we should add a very brief explanation to any ibox that uses the green check mark and the red x? I wouldn't have put myself through hoops had there already been such an explanation in the documentation at least. I've documented this info to help editors in the future. P.I. Ellsworth - ed. put'r there 03:19, 12 November 2021 (UTC)
Why not use old fashioned <ref>? Argument (D) the symbols actually say: "some editor has checked this and found it to be sourced, so you can trust it" without actual verifyable source. Why this extra, intermediate, decoupling step at all? In content space. One could use {{?}}, and hidden tracking categories. However, takes a serious RfC/proposal to change this system, and I don't have the time at the moment. -DePiep (talk) 09:48, 12 November 2021 (UTC)
Good points. The ref params are already set up to use actual sources, so it doesn't make sense just to check them off and not actually show the sources. The green check mark would be replaced with a [1]. So I see an upside to the red xs, but the green check marks should be replaced by (or augmented with) the actual sources. Wonder why it's been like that for all these years? P.I. Ellsworth - ed. put'r there 02:39, 13 November 2021 (UTC)
Technically, the {{cascite}} set & the CHEMVAL bot work with |..._Ref= (uppercase R). I recommend strongly recommend *not* to reuse these parameter names for something else. If we change the system, we'll do it right, once & from the start. -15:09, 13 November 2021 (UTC)
@Graeme Bartlett: I did code WP:CHEMVAL stuff like |CASNo_Ref= and {{cascite}}, but did not use the system (eg because I have no access to CAS site to check the source). Also, I am not enthousiastic about CHEMVAL, because (A) it introduces an extra class of "trusted editors" who are allowed to confirm an edit (how can one beome one at all?, still wondering), (B) the taskforce is not very active (number of open data issues (red crosses) did not decline meaningful over the years), and (C) it introduces symbols in Article content space, visible for the Reader, that are not clear nor easlily clarified (as Ellsworths posts show). Maybe more on this some other time & place. -DePiep (talk) 09:30, 11 November 2021 (UTC)
CheMoBot has not edited for over 3 years, so the changes are being manually done. Graeme Bartlett (talk) 10:02, 11 November 2021 (UTC)
Hadn't noticed. Also: doesn't alter the CHEMVAL issues I noted, really. -DePiep (talk) 09:48, 12 November 2021 (UTC)

Template-protected edit request on 2 December 2021

Change: adds |GHS_ref=. Will show in section header, same as |Hazards_ref=.
|GHS_ref= allows to add a single reference for the GHS parameters: GHS pictograms, signal word, H-phrases, P-phrases. At the moment there is no subheader for this "GHS" set (where this reference best could go), but for now the Hazards header is fine. Currently, the more generic |Hazards_ref= is used to enter this reference (eg, [26], [27]).
In the future, a more specific place may be available for to show reference link. DePiep (talk) 06:20, 2 December 2021 (UTC)
 Done * Pppery * it has begun... 17:05, 5 December 2021 (UTC)

Template-protected edit request on 12 December 2021

Change: 1. Four GHS data points grouped in one set format (under a new subheader); minor reordering in the infobox; 2. Allow new parameter |EUPhrases= for projected introduction.
Discussed: 1. Template talk:GHS phrases § GHS (set) in chembox, 2. Template talk:GHS phrases § local codes (EUH032)
Tests: .../testcases (set)#GHS (set) (new {{Chembox GHS (set)}}).
DePiep (talk) 08:57, 12 December 2021 (UTC)
 Done --Dirk Beetstra T C 11:10, 12 December 2021 (UTC)

Expansion depth exceeded

Resolved

I am getting expansion depth is exceeded 41/40 on N-Methylmorpholine, and many chemical articles are showing in this category Category:Pages where expansion depth is exceeded. Why? Display appears normal however. One think I notice is that p-phrases conks out at 26 entries. So it might be due to a large nesting of if statements in template:p-phrases and an edit on 16/11/2021 to chembox. Graeme Bartlett (talk) 10:49, 17 November 2021 (UTC)

You are right, 30 P-phrases in the article are tackled inefficiently. Made a quick first hack [28]. -DePiep (talk) 11:25, 17 November 2021 (UTC)
Problematic pages also ended up in Category:GHS errors (1) (280 as of now). I have reverted my recent, non-essential edits in {{H-phrases}}, {{P-phrases}}. I am working on a Lua-module for these. -DePiep (talk) 14:50, 17 November 2021 (UTC)

Template:Chembox entry (edit | talk | history | links | watch | logs)

FYI Template:Chembox entry has been nominated for deletion -- 65.92.246.142 (talk) 20:24, 25 December 2021 (UTC)

R phase templates

A set of mostly unused R phrase templates I have proposed for merge / deletion to the single (and actually used) R phrase template. Discussion is here: Wikipedia:Templates_for_discussion/Log/2021_October_28#Template:R1. Tom (LT) (talk) 07:38, 28 October 2021 (UTC)

FYI template:Chemical infobox has been nominated for deletion -- 65.92.246.142 (talk) 20:30, 25 December 2021 (UTC)

GHS statements: H-phrases, P-phrases templates

Forked into new section from resolved § Expansion depth exceeded

-DePiep (talk) 11:29, 18 November 2021 (UTC)

Redesign, rebuild

User talk:Graeme Bartlett I am rebuilding the H- and P-phrase templates (in Lua module). First and foremost, it will reproduce current functions (= show P210 as P210; preview warning & categorisation when error). Do you see any other useful functions we could use? (Already in mind: and automated list-all overview table). -DePiep (talk) 15:05, 17 November 2021 (UTC)
@Wbm1058: -DePiep (talk) 15:37, 17 November 2021 (UTC)
Thanks DePiep. We need to support more parameters. Perhaps 80 will be a limit to stop too much time wasting, but allow any reasonable number of P-phrases. Also sorting into numerical/text order may make sense. Graeme Bartlett (talk) 20:02, 17 November 2021 (UTC)
 Done see #All Up. That's all 86 H's, 160 P's, on the same page, sorted; no overflow. -DePiep (talk) 23:19, 17 November 2021 (UTC)
The new version will sort numerically, by default. Is informaticve, because number block can be a predefined class ("P200 - 230 is about flammable"). Will check what the max is. -DePiep (talk) 20:39, 17 November 2021 (UTC)
Another problem I sometimes have, is if I copy and paste numbers from de wiki, it includes some invisible unicode characters that stuff up the number lookup. It would be good if it could detect any characters that are not 0-9a-z and either ignore or give specific warning. (some numbers have a letter after them for H phrases). Graeme Bartlett (talk) 22:10, 17 November 2021 (UTC)
Will do so. "+" also allowed. That's the alphabet for cases like ['H360Fd'] and ['H361fd'] right? Is there a rule for such suffixes (pattern)? -DePiep (talk) 22:49, 17 November 2021 (UTC)
 Done -DePiep (talk) 23:09, 17 November 2021 (UTC)
The overview lists can & will be made available for mainspace, like in GHS hazard statements § Physical hazards. -DePiep (talk) 11:33, 18 November 2021 (UTC)
Question: will this new system also handle country specific hazard statements or are we sticking to the pure GHS system? --Project Osprey (talk) 11:00, 18 November 2021 (UTC)
About GHS hazard statements § Country-specific hazard statements then. At the moment, it does not. I I have build a more stable module to handle the "Annex 3" phrases (as the older templates do). So technical change only for now.
But it is well feasible to add local (EU, AU) phrases like EUH006 systematically. How would usage look like? Add local-specific entries to {{Chembox}} (as {{Drugbox}} has with legalities)? Ideas are welcome. For now, putting the module live will not obstruct any future feature. HTH. -DePiep (talk) 11:24, 18 November 2021 (UTC)
In that case we can decide later, focus on your roll out for now. Including them adds extra data but could result in duplication (for instance, AUH014 and EUH014 are the same), so there is a discussion to be had. --Project Osprey (talk) 11:37, 18 November 2021 (UTC)

Will there be a check for duplicate phrases? Currently, tetramethyllead, nodularin, sodium arsenite and uranyl acetate (all from PubChem, i.e. a inacurate source) contain H300 twice.
In my view, a reference with the source of the GHS labelling should be compulsory. --Leyo 21:30, 21 November 2021 (UTC)

Isn't that editors' issue? -DePiep (talk) 21:33, 21 November 2021 (UTC)
Are you referring to the latter? In my view, there should be a compulsory parameter for the GHS ref (otherwise → maintenance cat). --Leyo 22:47, 21 November 2021 (UTC)

Module ready for deployment

{{GHS phrases}} (talk), {{H-phrases}}, {{P-phrases}} now live (in ~2600 articles).
Minor issue: When "Omit Rule has been applied" (Category:GHS warnings (2)), the (helpful!) Preview warning does not show. Nothing broken, will look at this later on. -DePiep (talk) 19:05, 24 November 2021 (UTC)
Solved, likely a switchover-temporal bug. -DePiep (talk) 15:33, 25 November 2021 (UTC)
I will create an overview especially of the feature requests made above, that are not implemented (yet?). Documentation to update. -DePiep (talk) 19:11, 24 November 2021 (UTC)

Lua rewrite

Hello! I'm a crat from SqWiki. I was updating the code of some of our infoboxes according to the latest versions upon EnWiki and after {{Infobox drug}} I somehow made my way into {{chembox}}. Firstly I would say that this is one of the few infoboxes that I've found that doesn't follow the name convention to include "infobox" in its name. But that's not a problem per se. When I started importing it I saw that it included a large suite of subtemplates, some of them only including 1-2 lines of codes. I do understand that this is to make way of its modular function but I was thinking that maybe it would be better to rewrite it as a Lua module on its own and make the template just a wrapper for the invocation? Beside the benefits it can provide in future updates and maintenance, it would make internationalization easier as well. Aaand, if that could happen, a rename maybe could also be a wise option to undertake.

The ideal solution would be to first write the said module and then come here and ask for approval to make the needed changes but I've just started learning Lua myself and the best I can do is some small localized string manipulations. So maybe, if there's a good will for that, we can ask for help at WT:LUA? But first I'd be interested in reading your opinions on it. :) - Klein Muçi (talk) 22:07, 15 November 2021 (UTC)

@Klein Muçi: You can find a another version of the chembox here:[29] It does not use Lua but the module:infobox. But the project didn't like it. It had the same viusla output as the chembox (at that time). Christian75 (talk) 22:35, 18 November 2021 (UTC)
@Christian75, what was the rationale against it? I believe the general logic is to use a module (a module suite maybe) on its own which may be based on other modules as well. The said module(s) should be able to offer the same functionality and visual output as the current infrastructure does but by making use of much less code and thus making it easier to internationalize it. - Klein Muçi (talk) 00:12, 19 November 2021 (UTC)
The discussion is here Template talk:Chembox/Archive 11# (the section named "Discuss converting to use {{infobox}}". Christian75 (talk) 08:45, 19 November 2021 (UTC)
@Christian75, thank you! But, correct me if I'm wrong, I read that discussion just died out without people being exactly against the conversion. Is that right or are there other discussions where users expressed their against views more strongly? That is exactly what I'm proposing now, by the way. I believe as more years pass, this template will start to be even more isolated in the way it works considering the effect Lua has had on EnWiki (and globally). And as with any other infoboxes, the more years to pass, the more clean up work to be done in articles once changes do happen. If my words are worth anything, I would beg you to not let this case be another taxonomy templates case in the future. That case is already creating problems in a global scale. - Klein Muçi (talk) 08:57, 19 November 2021 (UTC)
There is a list of discussions at the bottom of Archive 11. Christian75 (talk) 09:08, 19 November 2021 (UTC)
@Christian75, again, correct me if I'm wrong but even after following all those links there I can't find any strong oppose arguments towards the idea. The first link is what you already showed me the first time, the second one gets closed as the first one does, just dying out and the 3 other links are archived badly and don't work. Maybe those have more strong arguments but they just send you back to the current talk page that we're talking because the archival function has failed. - Klein Muçi (talk) 09:17, 19 November 2021 (UTC)
I can only talk for myself. I'm not against using module:infobox. I think the current system of a enormous amounts of templates calling each other with strange parameter names makes it difficult to maintain. Editing article isn't easy if you aren't using it often. E.g. some parameters are using camel case and: CASNo, CASNoOther, and some: EC_number, CASNo_Comment. I'm not working with article chem boxes where often and have to look up the doc when I do. Christian75 (talk) 09:27, 19 November 2021 (UTC)
@Christian75, I was able to find the correct links in that page by searching manually. There has been a time where a conversion happened but it was deemed unworthy of use yet. And then again, the discussion has died out without any clear answer. 3 years have passed since then.
I'm pinging some of the original users in that discussion, maybe they can elaborate more on the topic: @DePiep, @Beetstra Klein Muçi (talk) 09:27, 19 November 2021 (UTC)
  • Archive_11#Chembox_2019 has an overview of the discussions. Whatever the conclusions then, one can propose now to use Module:Infobox for {{Chembox}}. -DePiep (talk) 09:56, 19 November 2021 (UTC)
    @DePiep, I just read them all but they have all ended in no clear conclusions. As I've stated in the beginning, I was hoping to ask for help at WT:LUA but I didn't want to go there without knowing better how the users involved with the template organically feel about it. Do you think the conversion would be a good idea if it was to provide the same functionality that the current infrastructure does provide? Would you have any opposing arguments towards it? - Klein Muçi (talk) 11:01, 19 November 2021 (UTC)
The conclusion then was: do not replace. Full stop. Better not go into re-interpretation of a 3-year-old talk.
Easiest & cleanest way to go is: write new proposal from scratch. Add gentle references (links) to earlier discussions (but still without the re-interpretation; editors can pick arguments from there and re-enter if they wish to). -DePiep (talk) 11:13, 19 November 2021 (UTC)
@DePiep, I'm sorry but I'll need to understand the problem fully myself if I am to be the one to open the discussion, especially if I'm reentering reference links to the old discussions. Where exactly was said to specifically not replace? What was the reason given for it? I literally must have missed that. I only saw some discussions about the conversion being started/proposed which had died out without any clear conclusion and in the end I saw one explaining that the change in articles had started where editor Christian75 was pro it and you and editor Beetstra had stopped the process by basically arguing that the new template was still in beta phase and couldn't be trusted for full release yet, and then the conversation had again died out. I checked the mentioned template now and it seems it had changed to just be a redirect to the current template now. What am I missing? - Klein Muçi (talk) 11:48, 19 November 2021 (UTC)
I don't want to push you off, Klein Muçi. The point is that we are supposed to be loyal to any conclusion. So I can not edit against that old one, based on a re-interpretation. Now a fresh proposal, could be 10 words ;-), is the royal route to such a change. Otherwise, later on someone might come along and make wiki-lawful objections. That said, I am thinking about such a change myself, but I need to develop my Lua skills first, and I want a strong setup for this beast (not just changing every parameter into Lua). And yes, current {{Chembox}} is too complicated to translate (so sq is Albanian, I learned). HTH-DePiep (talk) 11:43, 19 November 2021 (UTC)
@DePiep, no, you might have misunderstood my intentions. I'm not trying to say that the old discussions prove that we have the right to change it right away into Lua. I just want to understand if a conversion like this hasn't been done because of specific "against" reasons or because no one really came with a good enough solution or maybe no one had undertaken such a task before. And if there really were "against" reasons, I wanted to know what were they so I could understand what has been halting this process and if anything can be done about it. I'm not WP:BOLD enough to just go and request a change in an old, well established template without knowing its story just because it makes it hard for other wikis to use it. (Especially when a lot of users can argue against me/my proposal apriori by saying that I'm not active enough in chemical related articles or in EnWiki in general.) I'm just trying to understand, I'm not trying to reinterpret the old discussions and automatically give myself rights to make the needed changes (which I wouldn't be able to make them anyway because I don't have the skills). - Klein Muçi (talk) 11:59, 19 November 2021 (UTC)
(edit conflict) re 11:48: No need to redo old argumentations. Also no need to study the old discussions (I won't). All I know is that the conclusion then was "No", and I am loyal to that one. Now if you write the proposal, and simply mention but not redo the old discussion, and gently ping participants, a new conclusion can be made. After three years, and coming from a new participant, there is enough reason to restart the question. As I wrote, I will not start the proposal myself at this moment for practical reasons. -DePiep (talk) 12:06, 19 November 2021 (UTC)
@DePiep, assuming I am to follow that route, where would be the best place to hold that conversation? Is it WT:LUA? Or maybe some other technical page related to template changes in general? (Assuming this is not because then, per se, I would had already done everything that I could do.) - Klein Muçi (talk) 12:12, 19 November 2021 (UTC)
On this page, in a new == section. Add a notice on WT:CHEM I suggest. IMO it is not a WT:LUA issue, they can be invited later on for technical support. Short=better :-) -DePiep (talk) 12:17, 19 November 2021 (UTC)
@Klein Muçi: the problem was mainly that the rewrite was putting all parameters in one template, whereas the current template has subtemplates which group the items. With the many available parameters you get into a complete editing mess, plus that you have to convert thousands of pages. I think it would be helpful to show that we can have a one-on-one translation into the new infobox system otherwise I do not see any reason to convert - it creates more problems, whereas it does not really resolve anything. -- Dirk Beetstra T C 07:22, 21 November 2021 (UTC)
That is the 3y-old status. Waiting for Klein Muçi to create section "I propose to convert Chembox into Lua module". Don't have time myself now to start this now. -DePiep (talk) 08:11, 21 November 2021 (UTC)
@DePiep, I did put up a notice in WT:CHEM and WT:LUA about that BUT in regard to this section that we're currently talking. It really seems strange to me to open a new section in the same page to discuss the same thing. Even the title (Lua rewrite) is more or less the same as to what you propose (convert Chembox into Lua module). :P - Klein Muçi (talk) 08:36, 21 November 2021 (UTC)
Klein Muçi, we need a formal, new, clear consensus. Just ask it. As Beetstras post here shows: it is not that obvious. -DePiep (talk) 08:40, 21 November 2021 (UTC)
If you say so... - Klein Muçi (talk) 08:42, 21 November 2021 (UTC)
Or via WP:TFD? -DePiep (talk) 08:47, 21 November 2021 (UTC)

(arbitrary break)

Well, let me disagree with both of you. I would need to see a proper conversion first that we can discuss about - if you cannot maintain the same structure as currently (with the 'modules'/'sections') a regurgitation of the previous discussion will be an utter waste of time. Dirk Beetstra T C 08:48, 21 November 2021 (UTC)
Disagree. Before spending time on a new (sandbox) version, we need to remove that "no changes allowed" treshold. It's not about "let's see what the new version looks like", it is: do you support a change or not (more so: why?). Because: if we spend months of developing time, in the end someone (like you) could still come along and say "I don't like it", and "it was prohibited in 2018 already". -DePiep (talk) 08:58, 21 November 2021 (UTC)
@DePiep, I've been thinking about WP:TFD the whole time since I started making those notices in other pages but I thought about finishing everything where we started it. Now it would have been a good moment to restart it there but you insisted on having it here so, there we go. :P
@Beetstra, we're sort of in a deadlock here. One of my notices was in WT:LUA which got only 1 answer basically saying "we won't act without first knowing there's consensus there". So we can't have a module prototype without being open for it and we aren't open for it without seeing the prototype, apparently. :P And I believe situations like these have made the old discussions die out even years ago without clear yes or no answers. Also, maybe my newest post here will have made my intentions more clear but if not, and just to make sure I'm not misunderstanding you, the main point of this discussion is to precisely get rid of the subtemplate structure. It would of course retain its modular function, showing and hiding elements as needed but without having a lot of code located in many different subpages (having it located in one or two module pages) and thus not making it a nightmare to import, internationalize and, I'm assuming, even maintain and update for you.
From my perspective as an "outsider" it seems like most editors involved here "lack the courage" to make the needed step to change from "multipage chembox" to "1 module page infobox" and that's the general reason many of these sorts of discussions stop. I believe that we have to address that point and give a definite answer to it because no matter what route we choose to follow with this it will always come to "change the status quo and clean up after it in the articles" in the end. As I said above, a similar problem is already being discussed on a global scale and we don't know how to solve that. There are currently 87,000+ taxonomy subtemplates which make up for the way the taxonomy templates work in EnWiki. The list started normally and grew organically by using the same subtemplate infrastructure used at chembox to include more and more and more code and eventually grew to those proportions. Now there's no way the system can be imported somewhere else unless you start designing bots just for that task. A topic which has been discussed even at Wikidata, among many places here at EnWiki (you can also find an essay for it). Now, chembox isn't on those proportions yet (and may never be, considering the topics it covers) but the point is that in these cases, we should make up our mind if we are to ever act on it or not. If not, we let the system unfold organically, if yes however we need to act as fast as possible because the clean up work grows the more you let time pass. - Klein Muçi (talk) 09:32, 21 November 2021 (UTC)
@DePiep and Klein Muçi: It does not have to be a full complete working example. Let me just come back with a simple question (as that was the main issue why we did not go forward in 2018): Can you make the infobox work with sub-infobox templates that enforce grouping of parameters in the sub-templates. That is, can you do {{chembox|image=a.jpg|section1={{chembox identifiers|CASNo=1}} }} .. Otherwise you will be in deadlock anyway: if you cannot tell(/show) us that we can keep the exact same structure of templates as we currently have but with the layout of {{infobox}} you will get a negative answer. If your plan is to get rid of that subtemplate structure then I will give you a 'no' as answer, I will not agree with that, and that is where the worry was last time. -- Dirk Beetstra T C 10:10, 21 November 2021 (UTC)
@Beetstra, that's the article implementation. I personally don't have much interest how the parameters will be nested in articles. The best design would be a technical infrastructure that allows for flexibility, that is, writing/nesting/using parameters in different ways produces similar results, no matter how they are put. (A system with a lot of syntactic sugar maybe?) In this way it can accommodate uses from editors from different backgrounds. For example, me, not having dealt much with chemistry articles before, wouldn't know how to use it if it was to strictly retain that kind of infrastructure. Me, and many people from my homewiki community, are only familiar with the usual infobox model and would be in dead tracks when confronted with this added complexity. The usual infobox model being this:
{{Infobox something
|parameter1=value
|parameter2=value
|parameter3=value
...
}}
A model which you "detest" to be used for this particular template because of the extra long list of parameters one would need to use in such a way, if I've understood your correctly. The best outcome would be a flexible system that's also new-user friendly. But as I said, personally I'd be fine even with the current added complexity because ideally maintenance categories would be there to help users solve their problems. What I want to get rid of is the division of code in tens of different pages. The code for the whole infrastructure should be located in one place. How it gets implemented in articles is a different story. - Klein Muçi (talk) 10:28, 21 November 2021 (UTC)
That is the point, this is new-user friendly: identifiers nicely grouped together, CasNO is not somewhere between the boiling point and the NFPA on this page, and somewhere between the refractive index and the heat of combustion on another page. All nicely with the other couple of identifiers. And that is both an advantage for page editing as well as for maintaining the code. And it is not what I detest, it is what our chemical community found as the major issue and why previous RfCs did not go through. Dirk Beetstra T C 10:36, 21 November 2021 (UTC)
@Beetstra, why did you cherry-pick my answer? :P Again, code in article implementation is another thing. If you personally or the most part of the EnWiki chemical community think that that is the best approach to new users, I have no problem with that personally. I'm just asking for the code structure for that system to not to be divided into tens of different pages. With Lua we can hopefully have 1 single page for all that while providing the same functionality. The main point of this discussion which wasn't addressed by you. Changing the name from "chembox" to "infobox something" would also be a nice touch but, again, the main point is "code merging". - Klein Muçi (talk) 10:52, 21 November 2021 (UTC)
So, the only reason to make the infobox into one single module is so that the code is easier to maintain? -- Dirk Beetstra T C 10:58, 21 November 2021 (UTC)
Wait, if you want to simplify {{Chembox Identifiers}} so that it does not call so many further sub-templates then you have my blessing. If you also want to get rid of that level, then no. So not {{Chembox}} being able to hold ALL parameters, but one level below that as it currently is. Dirk Beetstra T C 11:07, 21 November 2021 (UTC)
@Beetstra, I'm an interface admin at my community and in general my work at Wiki, whatever the language or the project is, is directed towards the technical aspect. The practice used in this case is considered old, (to not say obsolete). I deal with the code myself so code is what I'm talking about. Could there also be beneficial changes to article implementations? Yes. If you ask for them, in general Lua offers more freedom in code writing than wikitext and faster responses from the server side so more things are possible than plain wikitext. But that's for users like you who deal with articles to ask for. I deal with the code aspect myself so the proposal is directed towards that side. Assuming there would be minimal or no changes at all in the way users already use the infobox, if that's what they wish for, why would you be against changing the backend code just so that it is easier to maintain, update and internationalize for people who deal with it? - Klein Muçi (talk) 11:17, 21 November 2021 (UTC)
@Beetstra, well, yes. That's sort of what I'm saying. To be able to deal with less subpages and have most, if not all, code merged into a single Lua module. The current article implementation should be able to be kept the same, if that is what you wish for. Or it can be further tweaked or enhanced in new ways of likings. But my proposal was directed towards the backend code.
In the end I must remind you that you shouldn't be scared of my words because this is all hypothetical. I personally lack the knowledge to do what I'm proposing so no change whatsoever will come from me. But if you and other users here agree to greenlight such a change (again, for the code), maybe some folks at WT:LUA can help us achieve it, firstly by giving us a prototype which can be modified to our liking along the way. - Klein Muçi (talk) 11:30, 21 November 2021 (UTC)
But then this whole discussion has nothing to do with the previous RfCs .. This is just merging the current hundred of sub-sub-templates into the template ({{chembox}}) and first-level sub-templates ({{chembox Identifiers}}, {{Chembox Properties}}, ...), so in the end we will have only 10-or-so templates to maintain. We had such a drive earlier (or similar), and I think that for that you would find support. I understood (my apologies) that this would also mean that we would get rid of {{Chembox Identifiers}} and that the parameters therein would then be merged into {{Chembox}} itself - that last merge I will oppose against vehemently. Dirk Beetstra T C 11:37, 21 November 2021 (UTC)
@Beetstra, well, of course. That's what I've been trying to say since the beginning. Maybe I wasn't too clear on my explanations because, as usual, in the head of the person trying to explain it, it's already clear enough. For that merging I proposed using Lua instead of wikitext because it's usually more efficient for these cases and I also proposed changing the name of the template just to be more aligned with the naming convention of all the other infoboxes but that's a minor detail.
But, just out of curiosity more than for practical reasons, why would you personally be against merging the final two levels of depth? - Klein Muçi (talk) 11:44, 21 November 2021 (UTC)

That is what I try to explain above: if you make it one level you have for some articles 80-100 parameters in one row without any 'enforced' grouping. That is for a casual editor daunting, for a regular editor a nightmare to work with. Most infoboxes deal with 10-20 parameters, and whether the birth date is the second or the seventh parameter is not making too much of a difference. Try to weed yourself through: 

{{Chembox
| Beilstein = 1718733
| VaporPressure = 5.95 kPa (at 20 °C)
| StdInChI_Ref = {{stdinchicite|correct|chemspider}}
| ImageNameL1    = Full structural formula of ethanol
| ImageFileR2_Ref = {{chemboximage|correct|??}}
| Appearance = Colourless liquid
| ImageNameR1    = Skeletal formula of ethanol
| pronounce      = {{IPAc-en|ˈ|ɛ|θ|ə|n|ɒ|l}}
| MagSus = −33.60·10<sup>−6</sup> cm<sup>3</sup>/mol
| Odor = Methanol-like<ref name="odorrr">{{cite web |title=Methanol |url=https://pubchem.ncbi.nlm.nih.gov/compound/Methanol |website=PubChem |publisher=PubChem |access-date=2 September 2020}}</ref>
| ChEBI_Ref = {{ebicite|correct|EBI}}
| UNII = 3K9958V90M
| H=6
| OtherFunction_label =
| PPhrases = {{P-phrases|210|280|305+351+338}}
| RefractIndex = 1.3611<ref name=crc2/>
| InChIKey = LFQSCWFLJHTTHZ-UHFFFAOYAB
| OtherAnions =
| NFPA-H = 2
| PEL = TWA 1000 ppm (1900{{nbsp}}mg/m<sup>3</sup>) <ref name=PGCH>{{PGCH|0262}}</ref>
| ImageFileL2    = Ethanol-3D-balls.png
| CASNo = 64-17-5
| ChEBI = 16236
| ImageFileL2_Ref = {{chemboximage|correct|??}}
| PIN            = Ethanol<ref name=iupac2013>{{cite book | title =  Nomenclature of Organic Chemistry : IUPAC Recommendations and Preferred Names 2013 (Blue Book) | publisher = The [[Royal Society of Chemistry]] | date = 2014 | location = Cambridge | page = 30 | doi = 10.1039/9781849733069-00001 | isbn = 978-0-85404-182-4 }}</ref>
| C=2
| NFPA-F = 3
| OtherNames     = absolute alcohol<br />alcohol<br />cologne spirit<br />drinking alcohol<br />ethylic alcohol<br />EtOH<br />ethyl alcohol<br />ethyl hydrate<br />ethyl hydroxide<br />ethylol<br />grain alcohol<br />hydroxyethane<br />methylcarbinol<br />
| DrugBank_Ref = {{drugbankcite|correct|drugbank}}
| SMILES = OCC
| 3DMet = B01253
| NFPA-S =
| LD50 = 7340{{nbsp}}mg/kg (oral, rat) <br>7300{{nbsp}}mg/kg (mouse)
| UNII_Ref = {{fdacite|correct|FDA}}
| ImageNameL2    = Ball-and-stick model of ethanol
| IDLH = N.D.<ref name=PGCH/>
| OtherCations =
| MeltingPtC = −114.14 ± 0.03<ref name=crc2/>
| ImageFileR2    = Ethanol-3D-vdW.png
| ImageFileR1_Ref = {{chemboximage|correct|??}}
| Name           = 
| StdInChI = 1S/C2H6O/c1-2-3/h3H,2H2,1H3
| ImageFile      = Sample of Absolute Ethanol.jpg
| BoilingPtC = 78.23 ± 0.09<ref name=crc2/>
| GHSSignalWord = Danger
| OtherCompounds = [[Ethane]] <br />[[Methanol]]
| DrugBank = DB00898
| Solubility = [[Miscibility|Miscible]]
| StdInChIKey = LFQSCWFLJHTTHZ-UHFFFAOYSA-N
| ChemSpiderID = 682
| ChemSpiderID_Ref = {{chemspidercite|correct|chemspider}}
| pKa = 15.9 (H<sub>2</sub>O), 29.8 (DMSO)<ref>{{cite journal | authors = Ballinger P, Long FA | doi = 10.1021/ja01489a008|title=Acid Ionization Constants of Alcohols. II. Acidities of Some Substituted Methanols and Related Compounds1,2|year=1960|journal=Journal of the American Chemical Society|volume=82|issue=4|pages=795–798}}</ref><ref>{{cite journal | vauthors = Arnett EM, Venkatasubramaniam KG | doi = 10.1021/jo00158a001|journal=J. Org. Chem.|title=Thermochemical acidities in three superbase systems|year=1983|volume=48|issue=10|pages=1569–1578}}</ref>
| UNNumber = UN 1170
| OtherFunction =
| ChEMBL_Ref = {{ebicite|correct|EBI}}
| IUPACName      = 
| ExternalSDS = <ref name="avantormaterials">{{cite web| url = http://www.avantormaterials.com/documents/MSDS/usa/English/C0407_msds_us_Default.pdf| title = MSDS Ethanol| access-date = 2018-07-08| url-status=dead| archive-url = https://web.archive.org/web/20120325005938/http://www.avantormaterials.com/documents/MSDS/usa/English/C0407_msds_us_Default.pdf| archive-date = 25 March 2012| df = dmy-all}}</ref>
| ChEMBL = 545
| Gmelin = 787
| Dipole = 1.69 D<ref name=crc89>{{Cite book | editor-last = Lide | editor-first = David R. | name-list-style = vanc | title=CRC Handbook of Chemistry and Physics|url={{google books |plainurl=y |id=KACWPwAACAAJ}}|edition=89|year=2008|publisher=CRC Press|location=Boca Raton|pages=9–55}}</ref>
| REL = TWA 1000 ppm (1900{{nbsp}}mg/m<sup>3</sup>) <ref name=PGCH/>
| MolarMass = <!--43.044 g/mol<ref name=crc2>{{RubberBible92nd|page=3.246}}</ref> -->
| GHSPictograms = {{GHS02}} {{GHS07}}
| NFPA-R = 0
| PubChem = 702
| StdInChIKey_Ref = {{stdinchicite|correct|chemspider}}
| NFPA_ref =
| ImageFileL1    = Ethanol-2D-flat.svg
| SystematicName = 
| LogP = −0.18
| O=1
| FlashPt = 14 °C (Absolute)<ref>{{Cite web|title=Ethanol|url=https://webwiser.nlm.nih.gov/substance?substanceId=18&identifier=Ethanol&identifierType=name&menuItemId=32&catId=58|access-date=2021-06-25|website=webwiser.nlm.nih.gov|language=en}}</ref>
| InChI = 1/C2H6O/c1-2-3/h3H,2H2,1H3
| CASNo_Ref = {{cascite|correct|CAS}}
| verifiedrevid  = 477167117
| IUPHAR_ligand = 2299
| Density = 0.78945 g/cm<sup>3</sup> (at 20 °C)<ref name=crc2>{{RubberBible92nd|page=3.246}}</ref>
| Viscosity = 1.2 mPa·s (at 20 °C), 1.074 mPa·s (at 25 °C)<ref name=crc92>{{Cite book| editor-last = Lide | editor-first = David R. | name-list-style = vanc | title=CRC Handbook of Chemistry and Physics|url={{google books |plainurl=y |id=pYPRBQAAQBAJ|page=6}}|edition=92|year=2012|publisher=CRC Press/Taylor and Francis|location=Boca Raton, FL.|pages=6–232}}</ref>
| ImageNameR2    = Space-filling model of ethanol
| Verifiedfields = changed
| Watchedfields  = changed
| ImageFileR1    = Ethanol-2D-skeletal.svg
| HPhrases = {{H-phrases|225|319|}}
}}<br>
</code><br>

These are a couple of main-template items, and 4 distinct groups in the current format on the article (here 83 parameters in random order). Put them back in the groups and you will have an easy editing experience. Identifiers with identifiers, properties with properties, safety with safety. I understand that for display it could still be exactly the same (all nicely grouped), but for editors it is a nightmare, and it does not really make it easy on template editors (or for LUA programmers, which are fewer that people who know their way around templates). -- Dirk Beetstra T C 13:48, 21 November 2021 (UTC)

@Beetstra: This example is disingenuous and rediculous. This shows how a vandal would leave it behind. Why would the |NFPH-X= parameters be dispersed? Why are no commentlines & whitespace used? Why would an editor not c/p blank parameter lists?
Already today, separate templates Chembox, Identifiers, Properties each have some 100, 175, 180 parameters. These could be reordered into chaos today, ie within current section setup. Incidentally, ethanol has chaos at the upper level at this moment: |Section2= is entered before |Section1= (Ethanol). btw, visible section ordering is random, Identifiers could just as well be shown at the bottom. Yes this template can use editing support, but enforced cutting up is not the right way. -DePiep (talk) 09:06, 22 November 2021 (UTC)
@Beetstra, can you also show to me the correct/current way how that infobox is written so I can fully see the difference? Maybe another one similar to it, utilizing most of the parameters in an article, no need to write it here. - Klein Muçi (talk) 17:40, 21 November 2021 (UTC)
Beetstra's example is from ethanol Christian75 (talk) 17:51, 21 November 2021 (UTC)
@Christian75, thank you! I'm a bit confused though. What exactly changes between the two examples? In first glimpse I notice the lack of section parameters in the above example. Does the number of parameters change as well? I did a very stupid counting where I counted the "|" characters in each case with Notepad++ and surprisingly there were 179 pipe characters in the above case and 193 pipe characters in the article case. The counting is very stupid because pipe characters may also be part of other "horizontal parameters" (just for the sake of naming the nested subparameters). So, can you help my untrained eyes by guiding me in what exactly changes between the cases? - Klein Muçi (talk) 19:54, 21 November 2021 (UTC)
I believe giving me just 1 isolated example of a group of elements grouped and then the said elements not grouped would be enough. It may sound silly but not having dealt with chemistry article editing before and seeing 83 parameters immediately got me really confused. I was unable to fully understand what exact kind of feature @Beetstra is pro keeping. Sorry in advance, just trying to understand better. - Klein Muçi (talk) 20:49, 21 November 2021 (UTC)
Reread the conversation for the third time. @Beetstra, is this about having certain elements (parameters) always grouped together, hardwired in certain positions? Do you think that their position should be fixed in articles because that way it makes it easier to maintain their use in the said articles instead of giving full liberty to editors to list them however they want because if they did that it would be too chaotic and therefore harder to work with the articles which utilized them? Have I understood you correctly? - Klein Muçi (talk) 21:01, 21 November 2021 (UTC)
(edit conflict) "... what exact kind of feature Beetstra is pro keeping" -- is exactly the point in question. {{Chembox}} has some 500 parameters. Keeping them organiseed in the edit screen is not the same as forcing an editor to research a dozen subtemplate documentations. For example, WP:VE, WP:TemplateData exist. -DePiep (talk) 21:04, 21 November 2021 (UTC)
@DePiep, yes, I'm confused at the same part because:
  1. Even if we want the order of parameters hardwired in fixed positions that can be done without having to have the code itself divided in different sublevels. The code can all be merged in 1 single template and that template (Lua module) can be coded in such a way that allows for parameter acceptance only in 1 single kind of order and produces errors in any other case (or any other similar solutions if this may seem a bit too extreme - the point is that there's no need for the code itself not to be merged in 1 single page, its rendering can be programmed how we want it to be)
  2. I'm not sure why we'd want the order of parameters hardwired. In my experience, usually when dealing with infoboxes, editors will just copy-paste the list of parameters from the doc page however it is and start filling it up with values. So 90% of the time the order would be fixed anyway. But maybe we want them in a fixed order to make article maintenance easier. In that case maybe we can set up a cosmetic bot job to deal with the remaining 10% of the cases that wouldn't follow the order suggested from the doc pages?
And, sailing a bit in unknown waters here but are we sure we really need 80-100 parameters for 1 infobox per article? I haven't checked the parameters utilized in details and maybe they're all needed. (I'm in general an inclusionist myself and I believe in the philosophy "the more, the better".) But MAYBE some of them can be merged together or can be deemed not that important to be in the infobox while they're elaborated in the article itself? Take my words with as much salt as to cover the whole Wikipedia because as I said I haven't studied the parameters.
...But maybe I've misunderstood everything so I'm interested in hearing @Beetstra's thoughts on this. - Klein Muçi (talk) 21:37, 21 November 2021 (UTC)
Enough of this. Won't keep explaining this. Beetstra@'s "current situation helps editors" is not that correct, because: it does not. There will be a single template (/module) that handles all parameters. If there are people who have issues with the parameter set, they should discuss that separately. -DePiep (talk) 21:45, 21 November 2021 (UTC)
@DePiep, personally I'd choose to take it in a bit more relaxed way and see what the other viewpoints on this detail are. Hard code maintenance is what made me start this discussion so it would be a bit hypocritical of me if I said that article maintenance are of no concern to this discussion. Even though, as I said, I strongly believe we can keep 1 single module and still preserve the actual subgroup functionality of parameters and even though my main interest is on the backend part, I believe it would be in everybody's interest if we could also give a solution to the frontend aspect "flattened parameters vs grouped parameters", given that it has been a point of dispute in the past. Of course if we can't reach any agreements on that we can still go on with the proposal in regard to the other aspects on which we agreed on but creating a possibility for a very thorough discussion is a good thing overall I believe. - Klein Muçi (talk) 00:02, 22 November 2021 (UTC)

(arbitrary break #2)

@DePiep and Klein Muçi: The argument that we expect editors to research a dozen subtemplate documentations is not true. The documentation is all clearly visible on Template:Chembox, that does not change at all. Only if there is a need for more exotic parameters they may have to search in a subdocument, but that is then also clear - you expect the exotic identifier to be in the identifiers-document, and the property-related parameters in the properties-document. It is earlier the other way around - now you would have to show all 500 possible parameters in one top document, which is more daunting than selected groups in selected subsections and/or subdocuments.
No, they are not grouped by importance. Above list is 86 parameters, as you state by your understanding all gibberish. But they belong to distinct groups - some are identifiers (CASNo, 3DMet, PubChem, Gmelin, Beilstein), some are properties (Appearance, molecular weight, boiling point, melting point), some is safety data (Flashpoint, the 4 NFPA-parameters, etc.). If you want to draw an analogue to a persons-infobox, we would put all date-related data in one group, all religion data in another group, all family-related data in another group - but for a persons-infobox that does not make sense, as most of those groups are just one or two parameters, here we have 16 identifiers on Ethanol, and 17-odd parameters relating to properties. Mix the two up and you have 33 which, after a couple of years of editing, will be in the random order that I generated above.
And yes, that Ethanol box needs so many parameters, Benzene has 87, Toluene has 77. There are topics on Wikipedia where infoboxes have a massive number of needed parameters. -- Dirk Beetstra T C 05:50, 22 November 2021 (UTC)
The problem here is not in documentation. Subsections can be kept in documentation, visually. (Though as you describe, one must know in which subtemplate/topic/section-name an (exotic) parameter is). Problem is that one is required to use subtemplate constructs.In the article, we can use <!-- grouping aids -->. And sure, current subsections prevent reuse (cross-usage) of info, e.g. indexes and chemical formula. -DePiep (talk) 07:44, 22 November 2021 (UTC)
@Beetstra, okay so:
  • A lot of parameters are needed;
  • They need to be ordered for frontend maintenance reasons;
  1. Now do you agree that all code can be merged into 1 page nonetheless preserving the current structure? As I've said countless of times, I won't be the one doing the conversion so maybe in the end we'd have more than one module page for that but the idea is that from the backend perspective is usually not mandatory to keep it in different pages for it to offer the same functionality. Wikitext templates usually need that kind of thing to offer that functionality but programming in Lua usually does not. The code can be in 1 place and be programmed to work and support a grouped parameters infrastructure. (Again, we're talking about the ideal case here. The practical example we get may be different.) Do we agree on this?
  2. Secondly, what do we think of the cosmetic bot job idea? Parameters are not grouped per se but every couple of weeks or months a bot runs through all pages transcluding chembox and fixes the order of the parameters to help keep them not deteriorating. This will of course be coupled with something else as well so the job wouldn't be cosmetic only, like the bot guidelines require. (In my homewiki cosmetic changes are normal but here aren't.) Would this be an interesting idea? Or is it a must that the grouping infrastructure must be part of the template programming in itself?
And as a side note, can you show me another topic where infoboxes have nearly 100 parameters? It would help me with my overall work with them. - Klein Muçi (talk) 07:59, 22 November 2021 (UTC)
@DePiep, yes that's more or less the point I tackle in my second question: How important is the "group identity"? If we really just need the sorting, than maybe a cosmetic bot job may be considered. If we need the sorting + group identity, we may resolve it with comments? And if we need the sorting + group identity + the subtemplate constructs (nested parameters) then that would require us to program it like that. But which case is it really? Because so far we've only talked about the first case where only order is needed. Is that true or has that always been in such a way for it to also mean + group identity + subtemplate constructs (nested parameters) and in reality is case 3? - Klein Muçi (talk) 08:12, 22 November 2021 (UTC)
I am sorry, user:Klein Muçi, but I am going to rhetorically ask: why is it so important to destroy the "group identity". It has worked for 5-10 years, no-one had problems editing with it, no-one had problems creating articles with it. Things are reasonably ordered and I haven't seen many complaints (if any) from people who could not place their new parameter in the right place. Instead, we insist that we abolish a perfectly fine working system so that we run the risk that people are just randomly going to put parameters and produce other problems just because 'infobox' does not support it and possibly/likely have to perform continuous maintenance (0-edits).
1) Yes, it can be done, but I do not see why we HAVE to do that (note that as a programmer myself I could consider constructs where the sections are 'fake' but enforced).
2) I think it can be avoided - en.wikipedia does not like 0-edits (not by bot, nor by editors/AWB), and these 0-edits are unnecessary (the template works without them) so that would find a lot of resistance. That means that a mess will stay a mess. But if you group (like now), there is no mess, ánd you do not need cosmetic edits.
I have no clue if it is elsewhere, these are likely the templates with by far the most parameters. But as I said below to DePiep: Why not enforce grouping by using subtemplates or enforced subgroups within the template as an added functionality and combine the best of two worlds. Why run the risk that pages turn into a mess when we have a perfectly fine, working solution to avoid it. I don't understand why. Dirk Beetstra T C 11:02, 22 November 2021 (UTC)
@DePiep: I don't think that requiring to keep materials in subtemplates is a problem, it works perfectly well, editors have done so, with the chembox, for 5-10 years now, and I have not seen any problems with people putting all parameters in the top chembox template or in wrong subtemplates ... It is well documented and people just copy/paste. There is NO problem with the subtemplates, there is no issue with editing, and it is all rather well organized. You can put grouping aids, but that has the same problem, someone adding a parameter will need to know in which group to put it, and because it does not matter, people don't need to and you may get a mess. The only viable option to maintain that is to have a bot doing 0-edits (which en.wikipedia absolutely does not like, not even manually) on pages to make sure that they are in 'our preferred order' - with people edit warring against it. Enforced grouping has never been a problem, so now we have to solve a problem that does not exist so we may/will/can problems for which we then have to perform maintenance to solve it. The only problem is that we have to convert to infobox and the new system is not capable of handling it, whereas the current system that can handle it and works perfectly fine can ... And then we have a bot having to do 11000 edits to convert all boxes.
Cross-usage of parameters ... I know it is not possible, but I haven't missed it at all, nor have I seen ANY discussion for someone asking for that. And in the worst case we then replicate one or two parameters to solve that in two subtemplates, but again, I haven't seen any templates where you would need it in the first place.
I really don't understand the underlying reason why we can't combine the best of the two: write an LUA infobox that does have the capability of using subtemplates. I really, really don't. Dirk Beetstra T C 10:49, 22 November 2021 (UTC).
@Beetstra: So you admit that "[currently] It is well documented and people just copy/paste", but after a changeover people somehow would start messing up the order? (As you did in your deceptive ethanol example above.) Anyway, we do have problems with using subsections because it always has prevented reuse of parameters. And anyway, the section order is not stable and may well be inconsistent both in sourcecode (as I pointed out for ethanol), and in visual result (inconsistent |SectionX= numbering, more likely in the sections below ID's and Props). You may not have met this as an issue (really?), but I can say that I have repeatedly encountered and mentioned it. Anyway it has factually limited the development (as in: feature was not implemented for being nigh impossible).
Some ordering assistance is welcome, but you are not asking for or looking for alternatives. Instead you cling to a non-designed feature/design flaw.
Problematic in your posting is that you skip the cross-section parameter reuse, now impossible. To be clear: I state that that is a missing feature, urgently needed to make more steps in infobox quality.
All in all repeating this setup would be a bad design flaw from the start, that will come to bite and hound every future change & improvement. -DePiep (talk) 14:10, 22 November 2021 (UTC)
Sigh, and now you expect an editor adding a next parameter to nicely put it in place? And that ad infinitum. The order of the subboxes is a feature, not a bug. Please show me some concrete examples of cross-subbox reuse of parameters. Dirk Beetstra T C 18:37, 22 November 2021 (UTC)
No I don't expect that. As we do not expect that today. In this nothing changes (editor will have to search for the parameter/-name they work on, and maybe c/p from documentation. As is done today. Your ethanol "example" is more like vandalism). My point is, that you describe this process as happening happily today, but claim chaos tomorrow somehow for the same. Changing order of subboxes a feature? -- no it isn't. There is no advantage for a reader in changing the order between articles. It's just never solved (except for manual corrections, mainly re the first three sections ID, Prop, Haz). And again: as I pointed out, ethanol today has strange section order(!) in the source wikitext, ie "chaos" you predict (iow, current setup does not prevent chaos while complicating editing). And no I don't have examples of cross-subtemplate parameter usage. Because that is virtually infeasible to program. I have not even proposed it in discussions—which is not "proof of no need" btw. It is hindring development. And I repeat that starting with subtemplates in Lua is bad design to say the least. You ase asked to join the search for other editing support options. -DePiep (talk) 19:24, 22 November 2021 (UTC)
@Beetstra, okay, so, to recap so we're not lost on words (the discussions are starting to grow in difficult-to-follow territory):
We agree that this is one of the few infoboxes that uses a number this large of parameters. And hence, because of its "exotic nature" (here referring to the large number of parameters), we require to have parameters grouped, something which doesn't happen in other infoboxes. This grouping infrastructure should arise by the code itself and not be dependable on cosmetic bots and doc pages and comments aren't enough to stop the lists on articles on deteriorating.
Now, in regard to "why is it important to destroy 'group identity'": It's not. At least, for me. I just asked to understand better your motives. I believe the whole discussion on this aspect stems from the exotic nature of chembox. Given that it's one of the few infoboxes that doesn't follow the standard of the other infoboxes people instinctively start questioning some things: If other infoboxes are right how they are and nothing bad is happening to them, should we also change this one to conform to those standards? If the grouped parameters standard followed here is better and more failproof, should we also change the other infoboxes standard to start having grouped parameters? (Person and geographical infoboxes could utilize some grouped parameters structures) If they don't because this is a "special case", is it really a special case? Maybe the large number of parameters is only that large because we have allowed it here to be like that whereas in other infoboxes it wasn't allowed? (Infobox film had a lot of parameters removed in regard to rating websites like IMDb, Rotten Tomatoes, etc.) And all these questions stem from the fact that infoboxes follow different standards in different topics, a subject which is far too general and big to cover here, in a discussion which already is getting out of hands.
Returning to the main point, assuming we devise such a Lua module that merges the backend code in one place while also preserving grouped parameters with group identity and given that you're coming from a programmer background yourself, why do you insist on having a 2-level hierarchy on backend? Why is it important to have the identifiers on a sublayer of the main part? This is not an opposing argument from me. I'm just asking to understand if you have any special reason for that preference I haven't yet thought of. To further prove that I mean no real oppose, let me bring you the case of Module:Citation/CS1, which is the module I'm mostly informed of, having dealt with it for quite some years now. In it you'll see (if you're not yet familiar with that) that the whole suite is made up of ~10 subpages, where code is divided on different subpages according to the use it serves for easier maintenance. If we are going to take the Lua road the end results are more likely to be something like that. But I'm not sure if your persistence on having a 2-level hierarchy is because of those reasons or not. - Klein Muçi (talk) 12:14, 22 November 2021 (UTC)
I think that the grouping would greatly help in keeping the deterioration to a minimum. I know it can be handled otherwise but that I do not believe that maintenance is a proper way of solving something that is avoidable.
Aspects of table creep were discussed earlier for Chembox. It has sometimes been handled by using a subpage with more data, but some subjects do have a lot of 'important' information. We might indeed consider to remove some of the identifiers, but to go to Properties of water: molecular formula, molar mass, appearance, density, melting point, boiling point, solubilities, vapour pressure, acidity/basicity, thermal conductivity, refractive index and viscosity are all properties that have an effect on our daily life (and I would argue some are even missing).
I have been re-iterating the point there: if you lose the 2nd layer, then the infobox for ethanol that I show above is just as valid as one where they are sorted alphabetically or sorted by type (in the same way as that is currently enforced). The big issue is that articles become difficult to maintain, anything goes. The only way to maintain clarity of the editing environment is by manual maintenance (manual or bot-assisted sorting).
I am not familiar with Module:Citation/CS1, but quickly skimming though the code I would expect that you could do the same with a 2-level system. I insist that the 2-level system has several advantages over the 1-level system, it is just as easy to program as a 1-level system. There is absolutely no reason why we could not write a 2-level system with LUA based on the infobox. Yet, the destruction of the 2-level system is made of major importance in this discussion as a problem which prevents LUA. Just go on and write the 2-level system using LUA, you have my blessing. -- Dirk Beetstra T C 12:53, 22 November 2021 (UTC)
@Beetstra, no, let me rephrase myself: We're fine with the 2-level system in articles. Let's have grouped parameters. I'm asking about the code that makes that possible in the background. Is it important for you that even the code itself should be divided in a 2-level system subpages? Most likely it will but is that a mandatory point? Or would you be fine even with 1 single module taking care of everything (while preserving the 2-level system in articles)? - Klein Muçi (talk) 12:59, 22 November 2021 (UTC)
@Klein Muçi: I learned to code in GW-BASIC (I am that old) ... monolithic spaghetti code with goto-statements. I guess that every well-thinking programmer that has to cover 500 different parameters which need distinct handling would split his program into parts. One piece of module is fine, but it is going to be massive. Dirk Beetstra T C 13:33, 22 November 2021 (UTC)
@Beetstra, okay. I just wanted to clarify that point to know what are the proposed hard limits in this project in general.
@DePiep, do you agree to go on with the proposal as it currently is? We can try Luaficating the current system and then, in the future, maybe we can ask for further changes, like those related to groups, etc. But in principle it looks like we're all in favor of Luafication and removing some of the current sublevels. Can we go on with the current conditions we've discussed so far? - Klein Muçi (talk) 19:37, 22 November 2021 (UTC)
@Klein Muçi: No. At the moment, Beetstra is claiming a crippled design from the start, which is unacceptable. -DePiep (talk) 19:49, 22 November 2021 (UTC)
@DePiep, but that is the current design we've been using for years. Even if it is crippled, Luaficating it would be a step closer to making it more healthy. :P And, as you stated earlier: This discussion is first and foremost to get rid of the 2018 prohibition of Luafication beforehand. - Klein Muçi (talk) 19:54, 22 November 2021 (UTC)
... And moreover... Vetoing the Luafication still leaves us exactly with that design. - Klein Muçi (talk) 19:59, 22 November 2021 (UTC)
No need to turn my words. AKA speak for yourself. Why buy a three-legged horse? Why "allow" Luafication while forbidding to use letters "a" and "s" in code? What you describe is sabotage into a cripple design. It is blocking future development. To be simple: I propose luafication exactly for its advantages. -DePiep (talk) 20:13, 22 November 2021 (UTC)
@DePiep, I'm sorry but how exactly is that "turning your words"? I've literally copy-pasted them. You were fine with that copy-paste when it was used the first time, this is hypocritical now.
Why buy a three-legged horse? Because we currently don't have a horse at all, of course. With a three-legged horse we may be able to get to the city somehow and possibly buy a 4 legged horse in the future and maybe even a truck. What is your proposal? It makes no sense even for your rationale to just keep the old crippled model. - Klein Muçi (talk) 20:21, 22 November 2021 (UTC)
You don't need a three legged horse to buy a four-legged one. For starters, you have the means already on the crooked one. But more important is: Beetstra is forbidding us to buy a four-legged horse. Not now, not ever. He requires the crippled code be build in. Putting a burden on every article chembox editor with about every edit. -DePiep (talk) 15:47, 25 November 2021 (UTC)
So stay with your (what you consider) two-legged horse. Whatever, DePiep, you have an infobox code based on LUA which is perfectly fine with modules (they have intentionally built that in), it is a matter of converting. But you insist in blocking that because you need to be able to reuse every one of the 500 parameters for the interpretation of the other 499 .. (or whatever the number is). You have a 4 legged horse, you insist in buying another 4 legged horse because you don't like another 4 legged horse. -- Dirk Beetstra T C 16:09, 25 November 2021 (UTC)
Nope. You are requiring that the section-based subtemplates stay in any future design. So that if we'd go for a quick replacement only, then in another few years time someone might get the idea to merge them into single-template, and you still will forbid that. You are requiring a substandard design, that will never be cured. All this, while the arguments for such an intentionally crippled design are not convincing—for me, they go straight against good UI design even. -DePiep (talk) 16:25, 25 November 2021 (UTC)
You are still to show me how this is a crippled design. There is absolutely no need to re-use parameters, an identifier is an identifier, a property is a property, a health risk is a health risk. --Dirk Beetstra T C 16:35, 25 November 2021 (UTC)
Crippled UI design (edit box): editors will have to handle mentally the otherwise useless code like
(simplified, clean)
}}
| Section2 = {{Chembox Hazards
| ...
| ...
}}
| Section3 = {{Chembox Pharmacology
| ..
}}
}}
Not only grasping the structure in a crowded editbox (each time one opens a page), but also maintaining it at the punishment of failure. This edit was needed today to fix such an error: [30]. (Cleanin up the UnkParameter category, I have met dozens of these over time). And these are the saved ones, we don't see the cancelled edits by a frustrated editor. Also, as I said, your ethanol example is rediculous as an argument. Oh and here is another example, from a live page [31].
Crippled Lua design. For starters: Splitting up the template will require repetition of code. No software dsigner should want that. Then there is maintenance to do for a dozen subtemplates/modules: synchronisation. (Having maintained the current subtemplates for some eight years, I can tell you: better do not want that.)
Then, your "we do not need template-wide parameters" is just an assuption. And arguments you use, like the 1-499, makes it look like you've not dived into this. (I did, since I am working on {{Chembox}} maintenance. Current setup re this is hindering obvious further development. That is: obvious if you are open for it). For starters: template-wide, we want to reuse indexes, qids (i.c.w. index), editor-help like parametersearch (I think CS1-like), possibly chem fomula, IDs, and there will be more but we have not been invited to think about these because it was not feasible anyway.
-DePiep (talk) 18:41, 25 November 2021 (UTC)
@DePiep, couldn't we get through with the initial Lua conversion now and let the future problems for the future?
Anyway, I believe we have long said all our arguments on this topic. I think the best we can do is open a RfC, hoping to gather more opinions from other users. Which is what I intend to do in the near future. - Klein Muçi (talk) 17:45, 25 November 2021 (UTC)
That is the issue, that is what I am arguing against: "future problems" are created today. When we want to solve these "in the future", someone will stand up and say "no that was forbidden". Also, we will spend our energy on substandard design constructs that will not allow even most obvious improvements. (btw, you could ask Beetstra the same, right? "Beetstra, why don't you allow single-template solution because this way you are ..."). -DePiep (talk) 18:03, 25 November 2021 (UTC)
@DePiep, I could ask Beetstra the same but it just so happens that his preferred method is the current norm now. So given that we all agreed on the Lua part then we can all take the current way and just add Lua into the mix. Then me, you, anyone else, can ask Beetstra or anyone else "Hey, can we switch to using a flattened infrastructure?" to which he most likely might reply "No, I refuse that." and to which we can reply back "But why?" and therefore have another discussion for that while having done some progress meanwhile. - Klein Muçi (talk) 18:33, 25 November 2021 (UTC)
short: no not "another discussion", it is the same discussion all over again. Anyway: redesigning Chembox better be done with a positive attitude towars good software design (including UI), not with outside restrictions. (Good to read that you know B.'s answers beforhand yourself). -DePiep (talk) 18:48, 25 November 2021 (UTC)
@DePiep, it was just a childish scenario to put into perspective what we can do and try to put a bit of a good atmosphere in the discussion. But sincerely, I have nothing else to add here. My wish, as I said many times already, was to start the update process and start walking with small steps from there. Even just the Lua conversion and the lowering of the subtemplates number would be very beneficial. If nothing else, global importation would benefit greatly. (And we're not counting the update/maintenance benefits that could be in for EnWiki.) You say that that must come as a package together with the added benefit of having ungrouped parameters, Beetstra says that's not a benefit... I can't mediate any further than this. The best we could agree was the general Lua conversion + subtepmlates' number lowering so I focused on those points. Apparently even those weren't enough for a better consensus so...
Hopefully I'll be back soon with a formal RfC for this and maybe we can have more participation there and we can reach a better consensus. I'm sad this discussion wasn't enough for us to get to agree on starting something but unfortunately this is where I stop. - Klein Muçi (talk) 23:53, 25 November 2021 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Template_talk:Chembox/Archive_12&oldid=1141985354"