Template talk:Chembox/Archive 13

Archive 10

Archive 11

Archive 12

Archive 13

Convert Chembox into Lua module

This is a follow up of this discussion. After learning in that discussion the past reasons for why the template is as it currently is, I was advised to make my request into a more formal discussion.

So my proposal is as follows:

• Make {{chembox}} follow suit by making it be dependent on Module:Infobox given that it is already de facto an infobox;
• Rewrite its code so instead of a multiple subtemplate design it uses a Lua module of its own (or a suite of modules if so needed);
• Change its name to follow the infoboxes' naming convention;

Wanting to keep this section as short as possible, the reasons for everything proposed above can be found on the discussion that is linked in the header.

Feel free to propose changes to details as needed. The main part of the proposal for me is to go from many subtemplates to one or a few modules. - Klein Muçi (talk) 08:55, 21 November 2021 (UTC)

• Support -DePiep (talk) 18:46, 21 November 2021 (UTC)

The design should not be by editor-level "modules" (as the proposal seems to suggest). One single lua module (=template). -DePiep (talk) 20:48, 21 November 2021 (UTC)

• Comment Chembox is hugely important to the chemical editing community, few of whom appear to monitor this page. I think as a courtesy a note should be placed on WP:Chem. --Project Osprey (talk) 19:58, 21 November 2021 (UTC)

  @Project Osprey, we already have. Check the talk page there. If you can help notifying other editors who might be interested in the topic, you'd do us all a favor. :) - Klein Muçi (talk) 20:29, 21 November 2021 (UTC)

• Sorry, must have missed that (there is currently a lot of 'chembox' stuff in my watchlist). Question will a full rewrite change many/all of the parameter fields and their ordering? As an editor, will I have to re-learn how to make a Chembox? Or are these equivalent to back-end changes that I wont notice? --Project Osprey (talk) 11:04, 22 November 2021 (UTC)

  @Project Osprey, we're striving for backend changes that I won't notice. Currently the code that makes the whole chembox work is divided into many subpages. The main idea is to merge all that code into 1 page or at least a way lower number of subpages that the current number. Now as a side point to that we're also discussing some details about parameter groups but the main point, at least the main point I wanted to reach in this discussion, is to deal with code merging in the background. If you are interested, you can participate in the discussion above about parameter groups but my advice would be to reserve comments for details like these to another future discussion we are bound to have because this discussion was supposed to only serve to discuss the idea in principle: Can we greenlight the rewrite of the template in Lua so we can merge the underlying code in 1 place? If the answer to that goes more towards "yes", then we can further discuss the practical details and their effects. - Klein Muçi (talk) 11:41, 22 November 2021 (UTC)

• Semi-support I support conversion to use standard Infobox for standardized infobox layout. I have no position on whether it's written in Lua or remain as regular template format. And maybe some {{Infobox drug}} could be factored out to share code with it. But the second idea doesn't make explicit whether the usage would be flattened (all parameters at top-level) vs retaining subtemplates (or submodules, or wrapped modules, or multiple entry-points to a module) for separate sections, so I can't support an unclear proposal. IIRC, that was a previous point of contention, so must be clear about that detail here. Are there any chembox sections that are used in other contexts (for example, a stand-alone {{chembox properties}} not as part of a full {{chembox}})? Having a monolithic list of parameters allows initial editors to be lazier when writing, but harder for later editors to find details to update. DMacks (talk) 23:04, 21 November 2021 (UTC)

  @DMacks, thanks for your opinion! The problem with the "unclear part" is because I am unable to make such a proposed change myself. The initial plan was to have a discussion about the possibility of the change here and if it was welcome, to ask for help at WT:LUA if someone could undertake it as a project and that's why the details were kept loose. Another important reason is that, if you had the nerves to read through the ever growing discussion above, you'll see that the main point for starting this discussion was the template's very high number of subpages (referred to as "subtemplates" in the discussion above). This makes internationalization, importation (tried it myself when when I started that process on my homewiki) and, I'm assuming, maintenance and update very hard. Rewriting it in such a way that all code is located in 1 single page (or at least a lower number than the actual number of subpages) would help with those aspects and usually in these cases Lua is the way to go. As the discussion evolved, the problem of parameter groups vs flattened parameters was put into attention and that's what we're still discussing currently above but personally I'd be fine either way. My initial personal interest was to merge the backend code so as to better support i18n. Hence why again, the details were kept deliberately loose to be chosen along the way by community consensus. - Klein Muçi (talk) 23:44, 21 November 2021 (UTC)

  Lazier is there the problem, I am afraid that we then get duplication of parameters (yes, I know, LUA would detect that) with the possibility that editors don't understand why their change did not come true, and if a list then devolves to the list I mentioned in a discussion above (75+ parameters in random order) then e would probably (as a chemicals community) have a lot of maintenance to do (sort the parameters when they get added).
  I do believe that we have limited use of the sub-templates as standalone, not sure how to find that though. I recall we have some articles that discuss a group of compounds and where we have discussions on properties grouped in that way. Dirk Beetstra ^{T C} 07:08, 22 November 2021 (UTC)

• Beetstra's ethanol example above shows that parameters must be in sections—a long list of anything-goes would be impossible to maintain. Writing a module is one problem but a trickier one that must be tackled first is the design of the syntax that the module would receive as input. That is, a first step would be to think about what wikitext an editor would see in an article. There are two factors. First, a clean and reliable way of entering/editing the information in sections is needed. Second, there has to be a realistic transition procedure to move from existing syntax to the proposed new syntax—tricky manual editing is not acceptable due to the certainty of introducing hard-to-detect problems. There are 12931 transclusions of {{chembox}}—I haven't investigated how many there are in articles. Johnuniq (talk) 02:28, 22 November 2021 (UTC)

@Johnuniq: Chembox is in some 11500 articles. The ethanol example by Beetstra is disingenuous: he has deliberately mixed the parameters into chaos (why would the |NFPA-X= parameters be dispersed?); a bot can order the arguments; one can use <!-- grouping comments --> (as documentation in blank parameter lists already does); and more editing support can be thought of.

Already separate templates {{Chembox}}, Identifiers, Properties each have some 100, 175, 180 parameters (with many data points do not have a reference or comment option). These could be turned into Beetra's chaos by themselves today already. Reuse of parameters not possible (indexes, chemical formula & element symbols—118!)

Current Section order (order in which sections=subheaders are shown in the infobox) is random (at editors like).

Simple: yes a lot of parameters to keep in order, and yes we need good (editing) support with it, and no this should not be enforced by degrading & complicating the editors interface, by crippling backend coding.

Now about your reply. Disagree on the "must" part. To be clear, in {{Chembox}} a Section requires a subtemplate with independent parameters like |Section7={{Chembox Explosives| para1=... |para2=...| }}. And conversely, all parameters require being used in a certain Section Subtemplate. Also, the "first" in your statement "syntax design must be tackled first" I disagree on. This discussion is first and foremost to get rid of the 2018 prohibition of Luafication beforehand. As long as people keep opposing this beforehand, syntax design is useless. -DePiep (talk) 08:43, 22 November 2021 (UTC)

I would strongly like to reinforce the last detail: This discussion is first and foremost to get rid of the 2018 prohibition of Luafication beforehand. We are just trying to create a general list of requests that we'll later be able to propose in a more formal manner either at WT:LUA or at WP:TFD. The discussion there will inevitably start tackling technical details in syntax design so it would kind of be an overkill to discuss it 3 times in a row. It's already hard now, maintaining 2 ongoing parallel discussions. This was supposed to be a discussion only allowing "relatively short answers" reserving most rationale discussing for the above discussion and yet, here we are. - Klein Muçi (talk) 09:00, 22 November 2021 (UTC)

@Klein Muçi: As I basically suggest below: combine the best of the two worlds and you have my blessing - turn the chembox-suite into a LUA-chembox-suite (but instead of the old 3-4 layer structure bring it down to 2 layers). The main argument against luafication was that that could only be done if everything was put into one layer (which, obviously is not true - if templates can do it then lua can do it just the same), and since there is resistance against losing the 2-layer structure and the 2 layer structure cannot be done there was not going to be luafication. Make it clear that luafication can, and is going to, maintain the 2-layer structure and this suggestion is going to go forward much faster. LUA should be an improvement on templates, giving more possibilities, not a step back.
(note DePiep: "Current Section order (order in which sections=subheaders are shown in the infobox) is random (at editors like)." <- that is a feature, and if I recall correctly even discussed as such. Dirk Beetstra ^{T C} 11:14, 22 November 2021 (UTC)

@Beetstra, I dealt with the layer hierarchy question in the discussion above. - Klein Muçi (talk) 12:21, 22 November 2021 (UTC)

@Klein Muçi: No need to cherrypick my words. I know them self well enough. The obstruction Beetstra is playing is part of the 2018 problem & blockade I want to get rid of. It is blocking future development. We're not gonna build a three-legged horse. Single-template is explicitly required. -DePiep (talk) 20:17, 22 November 2021 (UTC)

@DePiep, I'm sorry but you're literally blocking actual, present development. Greenlight the Luafication in the present and then we can solve the problems of the future. - Klein Muçi (talk) 20:25, 22 November 2021 (UTC)

@Klein Muçi: That future is here. This issue is already 3 years old. Virtually no development has been possible or occurred since. And you have not explained exactly who is blocking. -DePiep (talk) 08:50, 23 November 2021 (UTC)

@DePiep, you (read: User:DePiep) are currently blocking it now. We (including you up until yesterday) all agreed that this discussion was just to greenlight the Luafication of the chembox system. We all were able to agree on Luaficating the current system, lower its subpages numbers and change the name to include "infobox". Those were what we were trying to achieve. Re-read the start of this discussion (and even the old one) and you'll see those 3 points, points that you, up until yesterday, were fine with. After that you started vetoing the change with an extra mandatory point regarding the groups of parameters.

I ask you with modesty to stick to the initial plan and agree on carrying on with the Luaficating process. That's a step that needs to be taken and on which everyone agrees to. After that is accomplished we can start discussing about changing further details. Wikipedia won't be build in a single day. It gets built everyday with small steps. You have twice the amount of experience when compared with me in this project so you should know that better. Agree on making that step and we can later see what other steps can be taken. - Klein Muçi (talk) 09:06, 23 November 2021 (UTC)

@Klein Muçi: This is not a good description of my contributions or opinion. Given the topic, I am free to add to the talk. Please stick to content & arguments. Please stop framing & refactoring me in some incorrect position. Stay on content. -DePiep (talk) 11:38, 23 November 2021 (UTC)

@DePiep, you are free to open a new discussion about that. This discussion is about these 3 factors:

• Make {{chembox}} follow suit by making it be dependent on Module:Infobox given that it is already de facto an infobox;
• Rewrite its code so instead of a multiple subtemplate design it uses a Lua module of its own (or a suite of modules if so needed);
• Change its name to follow the infoboxes' naming convention;

Make {{Chembox}} use a flattened-parameters architecture; is currently NOT part of the three points above. Please use objectivity in judgement and stop unilaterally blocking the project in moving forward. You are totally free to open a new discussion for that after the phase mentioned above is completed because it doesn't conflict with your proposal. Even parallelly if you so wish. - Klein Muçi (talk) 12:01, 23 November 2021 (UTC)

{{Klein Muçi}} The topc is {{Chembox}}. My contribution in here is legit. Please stop reframing the discussion or my contribs. From here, it would be repetition of arguemnts so I stop. -DePiep (talk) 14:20, 23 November 2021 (UTC)

• As explained above I share the above concern from Johnuniq - 'a long list of anything-goes would be impossible to maintain'. IF that is the way to go, we will have to enforce manual 'sorting' of the parameters in the article. We have many articles with 75+ parameters (isopropanol, Ethanol, sodium chloride, Properties of water - all rather high profile articles, unless the Chemistry community is strictly maintaining the order in all 12000+ infoboxes, many of them will (slowly but surely) devolve in an impenetrable mess of parameters.

But put this into perspective: for the reader it does not matter whether the parameters are in one group or in enforced subsections, the display is the same (and the reader is the person we write for). For editors there is a difference - grouping of parameters is much easier to maintain and edit than having to find them. As long as the documentation at top level is sufficient, new editors (with respect to chemboxes) will understand what to do. For programming it is also not a difference, all software developers work with modules, include libraries, etc. etc. The only issue seems to be that the current master infobox is just not willing to do that, either because infobox does not support this we will not do this, or it is because Wikipedia is using infobox so therefore WP:CHEM has to use infobox as well. Both of those reasons are not the way Wikipedia operates. So if the reason is that we HAVE to comply with Wikipedia's general use of the infobox then I oppose. If the reason is that infobox does not, can not and will not support the use of subtemplates then I Oppose the change. If the reason is that there is no difference for the reader (which, except for being consistent between different types of articles there is not or hardly), and the programming is a lot of work, it may only make it worse for the maintainer of articles then I oppose the change. As explained above, I support collapsing the sub-sub-templates into the sub-templates, and I support converting the sub-templates and the main templates into LUA modules. I Support making the infobox capable of working with the subtemplates to enforce grouping and then implementing the infobox system (and actually, I think that would be a large gain for all of Wikipedia to have that possibility so that Wikipedia infobox maintainers have the choice of doing that). --Dirk Beetstra ^{T C} 07:03, 22 November 2021 (UTC)

That "a long list of anything-goes" is actually nonsense. Already it is clear that your ethanol-example abovbe is more a product of vandalism. Enforcing subtemplates is bad design from the start, and blocking future development. For starters, the template needs inter-section parameter usage. Which is relevant for the Reader too. BTW, interesting that you care asbout the Reader this way. So far, your only concerns are the editbox, and editors working on |NFPA-X= that somehow cannot find |NFPA-X= any more? It is amateuristic and bad design to enforce some grouping by introducing requirements. -DePiep (talk) 20:25, 22 November 2021 (UTC)

“the template needs inter-section parameter usage” - give me examples on what uses that, and if you are even a bit of a programmer you can easily do this. Yes, the ethanol example was extreme, but without enforcing order you will see pages organically go there unless you apply constant maintenance. DePiep, you are back to your old abrasive, combat ways, you are not willing to think in solutions. Things have to go your way or the highway. Dirk Beetstra ^{T C} 04:12, 23 November 2021 (UTC)

"not willing to think in solutions" -- hey, didn't I ask you here to think in other solutions to support your parameter-ordering/grouping? Why have you not responded to my claim that the § Beetstra ethanol example is a show of vandalism? You even mislead Johnuniq [1]. While, with the shoe on your other foot, you noted yourself that editors easily do "copy paste"?

Now here I won't argue for which template-wide parameters are useful. The problem is that you keep opposing the idea beforehand. You are invited to think about it yourself. My own " bit of a programmer" says: don't start with a crippled "design". Your cares for order are justified, but not the solution you keep promonting.I maintain that your design requirement is hindring improvements by definition. And complicating maintenance. -DePiep (talk) 08:47, 23 November 2021 (UTC)

OK, there is no need for the template wide parameters, we havedone without them for ages without problems.
I have already explained, and also here, that that is the end result. You insist to liken my example to vandalism (that is a strong term) and now misleading, which I duly note and why I called your language your typical abrasive, combat behaviour. Stop it DePiep. Dirk Beetstra ^{T C} 09:43, 23 November 2021 (UTC)

I was not misled. You must know that accusing Beetstra of vandalism is a sure sign of needing a wikibreak. Johnuniq (talk) 09:44, 23 November 2021 (UTC)

@Johnuniq:. Nobody said so. Someone wrote: "This shows how a vandal would leave it behind" [2]. Pls reconsider. The diff also points to strange effects re parameter order. (iow: why would an editor leave it behind like this, randomly scattered parameters? Why does an editor, working on say melting point, not know where to look for, and not copy/paste from /doc? As is done today already). -DePiep (talk) 10:01, 23 November 2021 (UTC)

If my words are worth anything, I'd say that editor DePiep isn't actually accusing anyone of vandalism but merely pointing out that the example editor Beetstra brought up was so deliberately chaotic that it would never happen in normal conditions, only in extreme ones. That's easier to see on the first instances that term was used. But given that it was pressed too much on that aspect, it started feeling like an accusation.

Again, if I'm allowed to give advice, I'd say that it would be better if we returned to the part where we focused more on the {{chembox}} template instead of the editors discussing it. This is an advice I need to read as well.

The only problem is that I believe we already tackled all the details of this discussion. Not very happy to repeat my words that I just said above but I believe that we were all (?) able to agree on the factors that this discussion was started for. Now, not having much more what to discuss we're starting to deal with the semantics of the editors involved in the discussion.

If editor DePiep can verbally claim its agreement on those 3 factors we discussed above (while retaining its opinion on flattened parameters) I can go on with a more formal request at WP:TFD. - Klein Muçi (talk) 10:02, 23 November 2021 (UTC)

“ Why have you not responded to my claim that the Beetstra ethanol example is a show of vandalism? You even mislead Johnuniq” … a show of vandalism, misleading Johnuniq. I was responding … ‘ but without enforcing order you will see pages organically go there unless you apply constant maintenance.’ Do you really think that someone will know where to add every parameter in an existing list? Forget it all, it is useless to discuss. Dirk Beetstra ^{T C} 10:50, 23 November 2021 (UTC)

For the record. I have been smeared "accusing Beetstra of vandalism" by Johnuniq [3]. Since Johnuniq has not responded to my reply [4], has not redacted or crossed out their accusation, I restate: the accusation is false, BF and a PA. As it stands, it disrupts the discussion into uselessness [5]. I note that Johnuniq has not argued on content after this contribution. Anyway one cannot expect from a smeared editor to discuss along as if nothing happened. That is the effect of BF accusation, and by maintaining their accusation Johnuniq is responsible for anylack of quality.

So, I did not say that. What I said about the § Beetstra ethanol example, is [6]: This example is disingenuous and rediculous. Also: This shows how a vandal would leave it behind. Also, the rest of that post was aimed at critique of the example (reads still to the point I note).

While I am at it, I point to this curious reasoning (no big deal, just a curiosity -- that could not be fleshed out though with smears clouding the page). 1. Beetstra posts this non-representative example, 2. Johnuniq says the example shows that parameters must be in sections—a long list of anything-goes would be impossible to maintain ("shows", "must" and "impossible"). Quite tough assumptions. 3. Then Beetstra continues I share the above concern from Johnuniq [7], which is actually a circular support of Beetra's own point based on an eh sub-optimal demo.

I hope Johnuniq can help recovering the threads. -DePiep (talk) 13:33, 28 November 2021 (UTC)

Replacement R-, S-phrases, EUclass with GHS: completed

• By now, the 2017 deprecated {{Chembox}} parameters |RPhrases, SPhrases, RSPhrases, EUClass= have been fully removed from usage. They have been replaced by modern {{GHS phrases}}, usually with a source check. For example [8], [9]. Tracking: Category:Chembox having DSD data (0).

Earlier on, per TfD, the R1-set and the S1-set of phrase templates were eliminated (Wikipedia:Templates for discussion/Log/2021 November 24 § Template:(S1), § Template:R1).

The parameters will be removed from {{Chembox}} (see this edit request).

Superfluous categories and subtemplates will be speedily removed.

Thanks @Leyo and Graeme Bartlett:. -DePiep (talk) 13:02, 27 December 2021 (UTC)

What with Hazchem images & templates?

Todo: reconsider Category:Hazmat templates (30). Now obsolete? -DePiep (talk) 14:42, 27 December 2021 (UTC)

Some of the templates there are used in pages like Dangerous goods or HAZMAT Class 1 Explosives, but whatever isn't used can be sent to TfD. Gonnym (talk) 17:32, 27 December 2021 (UTC)

I'm not familiar with the set/rules, won't start the TfD. For example, can that Class template remain while the {{Hazchem F|12px}} images are unused & deleted? -DePiep (talk) 17:36, 27 December 2021 (UTC)

Some of the templates might still be used/useful, e.g. in sections containing historical information. --Leyo 20:47, 27 December 2021 (UTC)

Whatever is useful should be used. From my experience, if something hasn't been used thus far in an article, it usually means it really isn't missing from it. Gonnym (talk) 19:26, 29 December 2021 (UTC)

Supplementary data page: link rows to remove

Demo-1: Ammonia (as is, Nov2021)

Supplementary data page
Structure and properties	Refractive index (n), Dielectric constant (εr), etc.
Thermodynamic data	Phase behaviour solid–liquid–gas
Spectral data	UV, IR, NMR, MS

Some 150 chemical articles have a data page, with name pattern: Ammonia → Ammonia (data page). When such a page exists, {{Chembox}} automatically adds section "Supplementary data page". Demo-1 is the Supplementary section for Ammonia/Ammonia (data page).

Background: Category:Chemical articles having a data page (130). A non-default data page name can be added by parameter: article 1-Propanol has |data page pagename=Propan-1-ol (data page), here too the Supplmentary section is added, as expected.

Demo-2: links explicit N

Ammonia (data page) [Supplementary data page]
Ammonia (data page)#Structure and properties [Structure and properties]	Refractive index (n), Dielectric constant (εr), etc.
Thermodynamic data	Ammonia (data page)#Thermodynamic properties [Phase behaviour] solid–liquid–gas
Ammonia (data page)#Spectral data [Spectral data]	UV/VIS spectroscopy [UV], Infrared spectroscopy [IR], NMR spectroscopy [NMR], Mass spectrometry [MS]

The problem is that the section does not add any info or data to the infobox, only wikilinks. Apart from the section header link to the data page, there are three wikilinks to data page #sections (see demo-2, the links made explicit). There is no check or guarantee that these #section targets are present or maintained in the data page. Also, there are six wikilinks to topics (straight articles). So, no Ammonia info is provided at all.

Demo-3: New section (to be) Y

Supplementary data page
Ammonia (data page)

I propose to remove all rows. What remains is a link to the data page, explicit—not hidden in the section title. Apart from this update from /sandbox, no changes are needed in Chembox or articles. Data pages an sich (existence, usage) are not in discussion here.

Same issue: SDS in Hazards

Demo-4: for SDS, same auto-link N

Hazards
Safety data sheet	See: data page [+some external page link]
GHS labelling:
Signal word	Warning

• Same issue with Hazards: linking to that Ammonia (data page) where a SafetyDataSheet (SDS) should be. Not maintained, not even a direct link (to a #section).Will remove this no-data-wikilink in the same go for the same reasons. Regular parameter |ExternalSDS= is available (ca. 1000 uses). -DePiep (talk) 07:39, 20 December 2021 (UTC)

Comments

Comments? -DePiep (talk) 20:53, 16 December 2021 (UTC)

Seems reasonable to me. YBG (talk) 07:45, 18 December 2021 (UTC)

Sounds good, reduces bloat in chembox. Graeme Bartlett (talk) 11:42, 18 December 2021 (UTC)

Yes, sensible per KISS principle. Mike Turnbull (talk) 12:24, 18 December 2021 (UTC)

Several of the data pages contain very little additional information. In my view it would be best to delete those and to add any relevant information to an appropriate section of the article. --Leyo 14:47, 20 December 2021 (UTC)

Y Removal of (data page) links: will go live. Changes to data pages (like merge into article): to be proposed & discussed separately please. (Ammonia (data page), Category:Chemical articles having a data page (130)). -DePiep (talk) 06:31, 21 December 2021 (UTC)

I nominated an extreme example for deletion: Wikipedia:Articles for deletion/Diborane (data page) --Leyo 11:06, 22 December 2021 (UTC)

Template-protected edit request on 21 December 2021

Changes extended, see below. -DePiep (talk) 12:43, 27 December 2021 (UTC)

• Please replace all template code with all sandbox code for:

1. {{Chembox SDS}} ← {{Chembox SDS/sandbox}} (diff)
2. {{Chembox Supplement}} ← {{Chembox Supplement/sandbox}} (diff)
3. {{Chembox Hazards}} ← {{Chembox Hazards/sandbox}} (diff)

Change: remove multiple automated links to data subpage as data (but not topical data); keep one explicit link (Ammonia & Ammonia (data page))

see also § More changes, below (27 December 2021)

Discussed /w consensus: see § Supplementary data page: link rows to remove

Tests, checks:

Before: /testcases11, previewed Ammonia with /sandboxes

After: in article Ammonia, especially Chembox Hazards "(SDS)" (no datapage link) and "Supplemental data page" (1 explicit datapage link).

DePiep (talk) 06:44, 21 December 2021 (UTC)

• More changes: Change to remove all R-phrase, S-phrase, EU-Class usage. 12:43, 27 December 2021 (UTC)

Per TfDs Wikipedia:Templates for discussion/Log/2021 November 24 § Template:(S1), Wikipedia:Templates for discussion/Log/2021 November 13 § Template:R1, and consequential article updates (from R/S phrases into GHS data). Tracking: Category:Chembox having DSD data (0).

Parameters |EUClass, RPhrases, SPhrases= are deprecated, abandoned and superfuous. Same for their subtemplates (including tracking/warning subtemplate {{Chembox DSD/warning note 2017 DSD-GHS}}).

This superimposed edit in {{Chembox Hazards/sandbox}} removes them. Original editrequest (21 Dec) will effectuate this removal through {{Chembox Hazards}}.

See also Template talk:Chembox § Replacement R-, S-phrases, EUclass with GHS: completed.

-DePiep (talk) 12:43, 27 December 2021 (UTC)

 Done. P.I. Ellsworth - ed. ^put'r there 14:32, 31 December 2021 (UTC)

Template-protected edit request on 31 December 2021

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

Change: Add {{Is redirect}} check before linking to data page like Bilirubin (data page) (no redirect). Test at /testcases 10 (page 10 prepared with R data page)

DePiep (talk) 15:13, 31 December 2021 (UTC)

 Done. P.I. Ellsworth - ed. ^put'r there 20:11, 31 December 2021 (UTC)

Template-protected edit request on 4 January 2022

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

Changes pertain to {{Chembox Supplement}}: show link to "Article (data page)". Example: Ammonia <==> Ammonia (data page).

Change 1. Default behaviour: if data page exists for the article, a link is automatically shown.

Now adding option |data page name=none, will suppress this automated showing of the data page link.

Change 2. Bugfix. When |data page name=<blank> (ie, the parameter exists), then the data page link did not show. Fixed: now it does.

New: template {{Chembox Datapage check}} is created to simplify pagename & exists steps (internal technical use only).

Tests & demo: see /testcases11. This testpage has data page Template:Chembox/testcases11 (data page).

DePiep (talk) 15:52, 4 January 2022 (UTC)

@DePiep:  Done —Uzume (talk) 19:53, 4 January 2022 (UTC)

RfC on making chembox an infobox

After 2 current discussions (Lua rewrite and Convert Chembox into Lua module) and some other discussions in the past years (they're mentioned in the discussions above and are part of the the archives) this is the first formal RfC that is being opened on the subject.

My proposal:

1. Make {{Chembox}}, a de facto infobox, a de jure one by changing the name;
2. Luaficate its wikitext structure to lower the vast number of its subpages;

The subject has been locally discussed some times but usually it has failed to acquire a large number of users involved so now we're trying the RfC way. - Klein Muçi (talk) 11:58, 1 December 2021 (UTC)

3. Adding: Directly following from the discussions mentioned, I note that essential part of the RfC question is whether to flatten {{Chembox}} (=reduce template depth) or not. (I participated in these earlier discussions, with an advocacy). @Klein Muçi:; added -DePiep (talk) 09:55, 16 December 2021 (UTC)

Survey

• Comment: This RfC is missing an critical point. As User:Klein Muçi knows from recent discussion on this, an essence of the question is whether the 10 Section subtemplates (like {{Chembox Hazards}}) must be kept or shall be abandoned. IOW, must all editors maintain constructes like |Section2={{ Chembox Hazards|paraHaz1=...|paraHaz2=...}} |Section3={{Chembox Explosive|...}} or shall we have a single template, with parameters working template-wide. -DePiep (talk) 19:16, 1 December 2021 (UTC)

That is not critical to this RfC, the above questions by KM can be implemented on either solution, they can be implemented keeping further flattening in mind, and the current infobox code has the code for modules built in, and flattening of the structure can also be done without using infobox code and luafication. They are two separate questions which are not critical to each other. You were from above well aware that KM’s primary point was infoboxification and luafication. Insisting on this point here is disruptive. Start another RfC for flattening after this concludes, and if that is successful that separate point can be implemented. Dirk Beetstra ^{T C} 03:56, 2 December 2021 (UTC)

Quite the opposite on all charges. The issue is that you, Beetstra, are opposing and forbidding flattening the template. You are insisting on maintaining the subtemplate |Section3={{Chembox Hazards|...}} structure. You are requiring that editors, all infobox editors, must edit in a multilayered editbox (with the complicated subtemplates) and that templateeditors like me must maintain suboptimal code. On top of this you are preventing reuse of parameters throughout the template (for example, existing substance indexes in Identifiers cannot be reused eg for those substances melting points or images). Also, I request that you redact / remove your accusation "disruptive"; opposing your point is not that. I strongly suggest that you stop using BF accusations. -DePiep (talk) 10:44, 11 December 2021 (UTC)

Whether CASNo_1 is mentioning the same compound as MeltingPoint_1 is a problem throughout, there it does not matter how the parameters are ordered, that is not a 're-use' of parameters, it is in whatever form we bring this infobox a matter of bookkeeping. Whatever solution we chose there, the infobox will never be suitable for handling multiple compounds. And bookkeeping is what landed us here in the first place.
There is nothing complicated about the subtemplates. Editors have been using them for the last 10 years or so. I agree that the template structure can be optimized, but that does not require flattening to single level. Dirk Beetstra ^{T C} 05:33, 12 December 2021 (UTC)

Since you have not withdrawn your BF accusation, further discusion with you is useless. Let's hope that someone else/somewhere else/somehow else the other mistakes in your posts are corrected. -DePiep (talk) 08:12, 15 December 2021 (UTC)

• Support provided that the |SectionX= modular structure is explicitly abandoned by design & intention (ie, no subsection templates/modules, single-template, all parameters template-wide). -DePiep (talk) 12:16, 1 December 2021 (UTC)

I add: new name {{Infobox chemical}} should be explicitly reserved for the changeover process (new name = new template/Lua). A most obvious way to help the switch process. -DePiep (talk) 13:38, 1 December 2021 (UTC)

Unfortunately, the proposal is ambiguous wrt the section templates. -DePiep (talk) 13:42, 1 December 2021 (UTC)

So, the Luafication should explicitly include flattening the template. See my § Proposal to remove the Section subtemplate structure. -DePiep (talk) 09:15, 16 December 2021 (UTC)

What aid, you put the new code in {{chembox}} et voila you have implemented the new luafied infobox. You don't need 12000-odd edits to implement. --Dirk Beetstra ^{T C} 17:10, 1 December 2021 (UTC)

It is not ambiguous, it is explicitly not part of this request, this request is just for conversion to infobox and luafication. --Dirk Beetstra ^{T C} 17:10, 1 December 2021 (UTC)

It is ambiguous, Beetstra. Or can you state that you do support flattening the template into single-level parameters? -DePiep (talk) 11:02, 11 December 2021 (UTC)

• Meh, this is a bit different than what I support - The 3-layer depth is a template problem which does not need luafication to go lower, that can be still done template wise. I therefore support lowering the depth from 3+ down to 2 (top level plus sections), and support luafication to streamline the background code of the chembox. There is a drive to even lower this further (flatten it completely), but I have not seen any significant reason why this is needed. Suggest the available 'module' structure possibility of the {{infobox}} for this. (note: changing the name to 'infobox chemical' is a bureaucratic waste of time and a complete waste of efforts). Dirk Beetstra ^{T C} 12:22, 1 December 2021 (UTC)

re name change: future name {{Infobox chemical}} reserved for changeover (new template uses new name). -DePiep (talk) 13:12, 1 December 2021 (UTC)

No, when we went through the previous changeover we kept the same name, there is no reason why we need to change the name except for compliance with what others do. --Dirk Beetstra ^{T C} 17:10, 1 December 2021 (UTC)

Name change is quite irrelevant, except that it can be useful in combination with code change. So I propose this new name reservation. -DePiep (talk) 11:04, 11 December 2021 (UTC)

(Beetstra, could you clarify: is this a reply or a !vote? pls consider using bolding and rephrasing the opening as it reads self-contradicting). -DePiep (talk) 05:19, 12 December 2021 (UTC)

I agree that it does not hurt to reserve the new name, but I stand with the point that doing 10.000 of edits just for the bureaucracy of it is useless. --Dirk Beetstra ^{T C} 05:28, 12 December 2021 (UTC)
This is an RfC. --Dirk Beetstra ^{T C} 05:28, 12 December 2021 (UTC) Dirk Beetstra ^{T C} 05:28, 12 December 2021 (UTC)

Haughty. Another reason to not reply. Content in your posts, if any present, to be ignored. -DePiep (talk) 08:18, 15 December 2021 (UTC)

• Comment, re "is Chembox an infobox?" — {{Chembox}} is a full and complete WP:INFOBOX. It has CSS class="infobox", and is used throughout as an infobox (for example, positioning in articles).

However, some quirks exist: (1) the name could be changed indeed, (2) it is a table not a {{Infobox}}, ie less responsive. Both pebbles could be removed by going Lua. With this, current RfC title is not exactly to the point. -DePiep (talk) 08:30, 15 December 2021 (UTC)

Adding: I repeat that a name change is not urgent nor required, and is trivial by itself. Such a name change best be reserved for (upcoming, desired) Lua-fication fronted changes (ie, changes at the article editors side). Allow me to note that, from having maintained this template for years, such a transition process can use any support it can find, including this name change. The alternative, like using 'temporal' Infobox chemical2 N, is needlessly confusing & complicating. -DePiep (talk) 07:38, 16 December 2021 (UTC)

Incidentally, WP:RFC states that name change proposals are not to be made through an RfC. So we should consider Question #1 moot. -DePiep (talk) 10:02, 16 December 2021 (UTC)

• Support in general. Since there isn't really a design to support I have no idea what "Luaficate its wikitext structure" really looks like. I will however support a better design which does not need so many subpages (including completely flattening). I also support the move to "Infobox chemical". Gonnym (talk) 09:37, 2 December 2021 (UTC)

{{chembox}} transclusion time report
across Ammonia, Ethylene, & Lactose articles

Transclusion expansion time report (%,ms,calls,template)
100.00% 1879.025      1 -total
 84.84% 1594.131      3 Template:Chembox
 27.71%  520.675      3 Template:Chembox_Identifiers
 25.10%  471.558      3 Template:Chembox_Properties
 17.09%  321.190     61 Template:Trim
 16.29%  306.117     19 Template:Chembox_headerbar
 13.85%  260.191      3 Template:Chembox_Hazards
 10.18%  191.306     45 Template:Unbulleted_list
  6.11%  114.828      6 Template:Cite_web
  5.75%  108.135      3 Template:Chembox_Elements

 Note:: The {{chembox}}es invocations from the said articles were placed into the sandbox and tested. The time report was take from html source code page. --AXONOV (talk) ⚑ 16:44, 7 December 2021 (UTC)

• Oppose rewrite Neutral as I'm not convinced that the template warrants rewrite in the Lua language. In terms of performance (see the report on the right), the most heaviest {{chem}}-sub-templates are the {{Chembox Identifiers}}, {{Chembox Properties}}, and {{Chembox headerbar}}. There are 54 subtemplates and we dont' know exactly how often they are used. Additionally, rewriting in Lua rises the cost of maintanance and will exclude contributors who don't know Lua language. All of this comes at zero benefit basically. --AXONOV (talk) ⚑ 16:44, 7 December 2021 (UTC)

@Alexander Davronov:

(1) Performance is not a reason to go Lua. I've maintained this template set for some eight years, and performance never is or was an issue.

(2) "rewriting in Lua rises the cost of maintanance"? Not AFAIK. Quite the opposite: current sectionstructure is prohibitive in further development & improvement. Just think of all the code repetition that the ten sectiontemplates require. Of course, just reproducing the sectiontemplates in Lua would make keep maintenance burden; a good reason why I oppose that, eh, design.

(3) 'Lua .. excludes non-Lua editors' -- true, but should enwiki abandon Lua then? And, from my maintenance experience here, in those eight years I have not seen many wikitext-editors engaging (not a reproach, just a statement of fact). -DePiep (talk) 10:59, 11 December 2021 (UTC)

@Alexander Davronov, I'd say that the last sentence of yours is rather harsh. It invalidates and ignores many points we've been discussing these days. I don't know if you've had time to read the past discussions and I'd totally understand if you haven't because there is A LOT to read (part of the reason I've refrained myself in participating in this RfC and why I'd urge other fellow "past commenters" to do something similar) but even if anything else mentioned above is not true (maintenance, etc.) the internationalization aspect is true. A lot of, not to say all, small wikis (and one may dare say even big wikis) rely on EnWiki for templates and modules. The wikitext structure with tens of subtemplates makes it really hard to import to other wikis just because the shear amount of manual work needed. This actually is what started this whole discussion, after me starting an importation process and stopping midway after finding out of how many templates I needed to import to make it work. Even to this day, SqWiki has a nonworking template because of the process being stopped midway. One can say that it's not EnWiki's job to look after such interests and at that point there's little I can add to change that person's mind but my belief is that in general, i18n should be part of technical development of every software needing it. Because of that, even on EnWiki, a lot of Lua modules are starting to provide a config. subpage related 90% to i18n aspects.

As for Lua excluding non-Lua editors... That really opens up a discussion that can become philosophical rather fast. This is an argument that gets tossed around a lot in these kind of conversion discussions and it's always leading to what user DePiep touches above. Lua is a means to an end in many cases, in this case to make it possible to have a lowered number of subpages compared to what we actually have. Users supporting Lua conversion, support it as a way to have a better outcome, they don't support it in a veneration manner on itself; It may as well be any other way that produces the same results or better ones. If you think Lua in general comes with an excluding factor in itself than that should be discussed in a general manner in regard to the attitude that we should hold towards it not in specific discussions because that's basically a point against that can be raised for every discussion ever in regard to Lua conversions that doesn't say anything about the specific conversion happening other than being against Lua in general. - Klein Muçi (talk) 13:52, 11 December 2021 (UTC)

@Klein Muçi: Given i18n rationale, did you ever estimate how much work needs to be done in order to transition to the Lua module? Do you have a list of subtemplates that require i18n? AXONOV (talk) ⚑ 14:24, 11 December 2021 (UTC)
@Klein Muçi: … If you think Lua … an excluding factor in itself … One will have to learn lua in order to update the template. It's a significant factor regardless of whether Lua is hard or not. AXONOV (talk) ⚑ 14:24, 11 December 2021 (UTC)

@Alexander Davronov, yes. The general idea is that after the transition has happened (and the number of subpages has been lowered, a key point) every other wiki importing it, that is copy-pasting it, in the more general sense, if we want to get pragmatic, would have less work to do. The same thing could (?) be said about maintenance because, in general again - in theory, if you like - maintaining a lower number of pages is easier than maintaining a larger number of pages. When I use "i18n" I use it to mean translation and copy-pasting (importing). I don't have a list of the subtemplates that require translation, even though I believe there wouldn't be a lot because, if I'm correct, they mostly serve technical purposes (hence why I think the template can benefit from their compression into a module), because I never got to finish the importing process at my homewiki. What we usually do when importing templates is to finish importing each component then try it on an article or sandbox page with every value used and start translating and fine-tuning its elements to our community's needs.

As for the Lua part, I'm not talking about the supposed innate difficulty of Lua. I'm saying that given that Lua is allowed on the project, points such as "Lua provides an excluding factor" are a bit "strange" to be seen in specific discussions regarding Lua conversions because they disagree with the fundamental point of the discussion itself and yet they are there a lot. In these cases it would be better, according to my viewpoint, to have a specific discussion in terms of "Should we allow Lua or not and if yes, on what guidelines?". I hope I have been more clear in my explanation now. - Klein Muçi (talk) 16:42, 11 December 2021 (UTC)

@Klein Muçi: …I use it to mean translation and copy-pasting (import)… This can be easily done by using built-in mediawiki functionality Special:Export/Special:Import (google for details). You can export entire list of subtemplates, translate them, and import into the local wiki (administrator privileges will likely be required) by few clicks. Why not to use it instead of lua? All the hardwork can be easily done. I will provide the list of sub-templates below (it may be incomplete). Hope it helps. AXONOV (talk) ⚑ 17:34, 11 December 2021 (UTC)

List of templates to export/import

Template:Chembox 3DMetl Template:Chembox 3DMet/format Template:Chembox AllOtherNames Template:Chembox AllOtherNames/format Template:Chembox CASNo Template:Chembox CASNo/format Template:Chembox CalcTemperatures Template:Chembox CalcTemperatures/doc/parameter list (edit) Template:Chembox ChEBI Template:Chembox ChEBI/format Template:Chembox ChEMBL Template:Chembox ChEMBL/format Template:Chembox ChemSpiderID Template:Chembox ChemSpiderID/format Template:Chembox CompTox Template:Chembox CompTox/format Template:Chembox DrugBank Template:Chembox DrugBank/format Template:Chembox ECNumber Template:Chembox ECNumber/format Template:Chembox Explosive/doc/parameter list (edit) Template:Chembox Footer Template:Chembox Footer/doc/parameter list (edit) Template:Chembox Footer/tracking Template:Chembox Footer/tracking/messagebox test (edit) (semi-protected) Template:Chembox Hazards/doc/parameter list (edit) Template:Chembox IUPHAR ligand Template:Chembox IUPHAR ligand/format Template:Chembox Identifiers Template:Chembox Identifiers/doc/parameter list (edit) Template:Chembox Indexlist Template:Chembox Indexlist/format (edit) Template:Chembox Jmol Template:Chembox Jmol/format Template:Chembox KEGG Template:Chembox KEGG/format Template:Chembox Pharmacology/doc/parameter list (edit) Template:Chembox Properties/doc/parameter list (edit) Template:Chembox PubChem Template:Chembox PubChem/format Template:Chembox RTECS Template:Chembox RTECS/format Template:Chembox Related/doc/parameter list (edit) Template:Chembox Structure/doc/parameter list (edit) Template:Chembox Supplement/doc/parameter list (edit) Template:Chembox Thermochemistry/doc/parameter list (edit) Template:Chembox UNII Template:Chembox UNII/format Template:Chembox headerbar Template:Chembox image Template:Chembox image cell Template:Chembox image sbs Template:Chembox image sbs cell Template:Chembox templatePar/formatPreviewMessage

@Alexander Davronov: KM is absolutely right to ask for a Lua infobox. As for your list of oldschool "templates to convert by a few clicks": a rubbish list, and it illustrates that your "it's easy" is disproven in step 1 (while the correct list is availablke in two clicks). BTW @Klein Muçi:, translation & foreign maintenance would be a lot easier if we cut out section-splitting. In fact I would not advise any i18n editor to spend time on such a construct, be it Lua or parsedtext. This from someone who maintained this box set for 8 years. Now back to the question: full Luafy or not? -DePiep (talk) 18:55, 11 December 2021 (UTC)

Alright if you insist on rewrite in lua I won't oppose that. I don't find lua very user-friendly language but it doesn't matter. There is no difference whether the list you import/export is correct one or not. The said built-in import/export feature may still be used as an ad-hoc solution for the said problem. Count me as neutral in this RfC. Regards. AXONOV (talk) ⚑ 19:11, 11 December 2021 (UTC)

@Alexander Davronov, thanks for bringing that functionality! Unfortunately that does require an intermediate step with Phab help to enable import from EnWiki to SqWiki. Currently we only have it enabled from SqQuote. Nothing that can't be done but just putting this here to say that it is not a priori enabled. Considering all these imports we've been doing manually from EnWiki lately it may be time we enable it from EnWiki also. Just so we're clear, personally I don't have any stronger love for Lua when compared with wikimarkup. The key element was to just make the subpages list lower and Lua was thought as a possibility because of past similar examples that had benefited from it. If you or anyone else can provide the same functionality in another way, you should feel free to do so. After all, we have nothing in practical terms currently. Even though, for the sake of not deviating of the RFC's initial state it may be better to reserve such projects for another RFC. - Klein Muçi (talk) 02:11, 12 December 2021 (UTC)

Proposal to remove the Section subtemplate structure

I propose to remove the Section subtemplate structure from {{Chembox}}. That is, to remove current |Section2={{Chembox Identifiers|...}} setup, also called modular setup. The change will effect article-side (editbox, for all article editors), and template maintenance (backoffice). The change is also called "flattening" (=reduce the template depth).

While this change could be made in current building-table-by-wikitext-parsing (in theory at least), the viable route is Luafication of the infobox.

Current situation

See also {{Chembox/doc/chembox design}}

Below the regular top parameters (like |Name= |ImageFile=), {{Chembox}} Sections are to be entered as subtemplates. Each Section subtemplate, handles its own header and parameters (formatting, presenting); a 'child' template in the outer {{Chembox}} table.

1. {{Chembox}} (top, 82 params)
2. {{Chembox Explosive}} (5)
3. {{Chembox Hazards}} (38)
4. {{Chembox Identifiers}} (206+50 CHEMVALID _Ref)
5. {{Chembox Pharmacology}} (38)
6. {{Chembox Properties}} (196, incl 118 element symbols)
7. {{Chembox Related}} (6)
8. {{Chembox Structure}} (18)
9. {{Chembox Thermochemistry}} (16)
10. {{Chembox Supplement}} (0)
11. {{Chembox Footer}} (0)

655 parameters (circa, 2021-12)

{{Chembox
| Name       =
| ImageFile1 =
| ... <!-- Chembox (top) parameters -->

| Section1 = {{Chembox Identifiers
| index_label    = A
| index2_label   = B
| index_comment  = A-substance
| index2_comment = B-substance

| CASNo  = 
| CASNo2 = 

| ChEBI   = 
| ChEBI2  = 

| ChEMBL  = 
| ChEMBL2 = 
| ... <!-- more Indentifiers parameters -->
  }}

| Section2 = {{Chembox Properties
| MeltingPtC =
| BoilingPtC =
| ... <!-- more Properties parameters -->
  }}

}}

The numbering in |CASNo= |CASNo2= is called indexing, and allows to enter & distinguish multiple substance identifiers.

Current issues

The possible issues arising from using parsing wikitext templates (instead of a lua module), by itself, are discarded here. The issues are in design & usage. That said, we assume any solution will be made through Lua, not in parsed templates.

• Design & development: Since parameters are not shared between sections-&-top, they can not be reused in an other Section. It is not possible to use the index-setup (which is available in Section Identifers only) for the same substances in images, names, melting/boiling points, chemical formula(!), hazards, etcetera.

Also, this parameter compartimentation hinders using Wikidata fruitfully. Adding indexed parameters |qid=|qid1=|qid2=|qid3= for the indexed distinct compounds, would allow to call Wikidata values (like |E number=, ECHA InfoCard ID=, DTXSID= already done for page-QID), and other compound values to show or to compare (say, use or compare melting point per indexed compound).

• Article editor: Extra structures in the editbox: An editor, any article editor, must comply with the extra |SectionX= structure. All edits must retain the |Section2={{Chembox Identifiers|...}} code setup. Also, when adding a Section, this structure is required. That is: this is before any content edit to the parameters is made. (this maintenance category has shown many such errors over the years [10] [11]).

Note that in the code example above, whitespace is used for illustration, and no 'distracting' data input is present. In articles, this not the case.

• Edit support: with Sections and parameters spread over many templates & documentation pages, it is hard to support an editor. There are no one-click routes to, say, a parameter list or blank Sections frame & parameterlist.

• Maintenance: In the backoffice, many code setups have to be repeated over all Section subtemplates. For example: parameter whitelisting, error/warning/tracking messaging & categorisation, upper (table/infobox/error&warning) formattings. This is complicating and putting off changes altogether. For example, when working on a data point, a three-deep sandbox stack is needed.

• Reuse elsewhere: having a stable chemistry data processing setup for 100 or 200 values like ID and melting point (say: reading, tracking, linking, WD-checking, formatting, presenting, styling), we can reuse that outside of {{Chembox}}. Comes to mind: {{Infobox drug}} (already happening although elaborate), non-infobox data sheets & boxes, on data pages (like this). And finally, easy translation into other wikis (i18n) comes within reach.

Not an issue

• Interestingly, the circa 150 datapoint templates (leaves, doing the individual data processing & formatting) are not complicating in this topic. Also, no performance issues were reported or experienced all those years.

Afterthoughts

• (A) Once a lua module handles parameters, data & formatting, we could consider a variant presentation in tableform, to present compounds in overview (~ multiple Chemboxes side-by-side). See Category:Multiple Chemboxes (39). I note thate most of these have images-per-compound (ie, images are index candidates once the input is flattened). -DePiep (talk) 06:42, 18 December 2021 (UTC)
• (B) Flattening would allow the formula, being an identifier too, to be put more in top. Or given any other priority & usage. -DePiep (talk) 04:37, 9 January 2022 (UTC)

Transition

I propose, and strongly suggest, that the transition be made as an explicit conclusion of § RfC on making chembox an infobox.

-DePiep (talk) 09:12, 16 December 2021 (UTC)

Comments

• Flatting helps editors as it is easier to fill in parameters without requiring to call another template. It is also better for the visual editor I believe (not sure how it even handles such templates). So you have my vote here. As an unrelated comment as I noticed while looking at the snippet above, the parameter usage should really be standardized. |ImageFile1= vs |index_label= is not a good design. --Gonnym (talk) 12:00, 16 December 2021 (UTC)

OK, thx. Yes param naming is chaotic. Not sure we should change this during this transformation (maybe a slow, next phase CS1-like cleanup could be done. Or, once params are in a lua-module, systematic parameter synonyms can be added & made available). -DePiep (talk) 12:29, 16 December 2021 (UTC)

Yeah, it should be done after to make life easier. Gonnym (talk) 12:50, 16 December 2021 (UTC)

I'm thinking about making names abstract internally, like |CASNo3_ref= → {"casrn", index, "ref"}, asap after reading. Processing, ordering, wd, i18n then is just matter of bookkeeping ;-) Hope it doesn't get too boring... -DePiep (talk) 21:13, 16 December 2021 (UTC)

Chembox, Occupational hazards (OHS/OSH): refinements

• Useful links

Parameter usage report for Template:Chembox Hazards. (F3-find parameters "Hazard" (EyeHazard, ...) for actual usage).

GESTIS example has section "Occupational health and first aid".

PubChem example has like "7.1.2 Hazard Classes and Categories / Skin Irrit. 2 / (100%) / Eye Irrit. 2 (100%) / STOT SE 3 (100%)".

Sigma-Aldrich example todo

I propose to group & rephrase the five Occupational safety and health (OHS/OSH) hazards. Added new |GHS_ref=. Apart from the Main hazards (1300), the minor ones won't exceed 30 articles.

A demo is at Template:Chembox/testcases (set) § OHS set (new). Mention OHS/OSH equally? Any comments? @Leyo and Graeme Bartlett: -DePiep (talk) 19:05, 19 December 2021 (UTC)

Are main hazards and the other parameters grouped in the box just for OHS? I thought that they would be much more general in application. Our documentation does not specify what these are for. One issue for the subheader lines is that the background is a bit darker and make the text harder to read. Graeme Bartlett (talk) 21:01, 19 December 2021 (UTC)

(ec) re GB. We could apply a wider title for these. Anything ~formal we can use? (GESTIS has a large section "Occupational health and first aid" [12]). In any case, I don't those words floating around like loose remarks. And current (lefthand) labeltext is a bit sloppy, up for improvement. There is no need to wikilink "eye" IMO. Lightened the headergrey. -DePiep (talk) 21:24, 19 December 2021 (UTC)

pubchem has like "7.1.2 Hazard Classes and Categories / Skin Irrit. 2 / (100%) / Eye Irrit. 2 (100%) / STOT SE 3 (100%)". that is, a formal recording. -DePiep (talk) 21:27, 19 December 2021 (UTC)

I don't think such a section is needed in the box. GHS is sufficient and more information may be provided in the text. --Leyo 21:17, 19 December 2021 (UTC)

I've repositioned this subgroup more below (see testcases). Removal is a different topic, please propose separately. Don't know enough background of these to advocate that. See linked examples, they are in pubchem and Gestis AFAIK. -DePiep (talk) 22:20, 19 December 2021 (UTC)

Main hazards almost always duplicates what is in EUClass, or now represented by GHS pictograms. But it could be more usefull if there is something outstanding or different, eg pyrophoric, radioactive. Graeme Bartlett (talk) 00:44, 20 December 2021 (UTC)

(sandbox demo's not working pending edit request re data_page) -DePiep (talk) 07:33, 22 December 2021 (UTC)

Restart: group & order OHS in section Hazards

Now that the sandbox is free to test&demo, I reopen my proposal to

• Group existing terms for Occupational safety and health: Main hazards, Ingestion, Inhalation, Eye Skin.

Main has some 1100 uses, the other four appear on 16 different articles altogether.

• Order: I've put the OHS set in top, and SDS at the bottom because it's an external link.
• Fixed texts: see demo
• Demo: /testcases_(set)

Comments, ideas, a Go Ahead? -DePiep (talk) 18:16, 4 January 2022 (UTC)

@Graeme Bartlett and Leyo: -DePiep (talk) 17:00, 5 January 2022 (UTC)

Y preparing top go live. Only about Hazards grouping, ordering (notg removal)-DePiep (talk) 18:32, 11 January 2022 (UTC)

Template-protected edit request on 11 January 2022

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

Change: Groups five existing parameter rows into one set (header + subrows): Occupational safety and health (OHS). Uses existing parameters. Main hazards, Eye hazards, etc. Labeltext simplified. Reorder Hazards section rows.

New: |OHS_ref=, {{Chembox OHS (set)}}; Tests: See /testcases (set)

Support: see § Chembox, Occupational hazards (OHS/OSH): refinements. Note that deletion of parameters needs a separate talk.

DePiep (talk) 19:16, 11 January 2022 (UTC)

 Done. P.I. Ellsworth - ed. ^put'r there 02:17, 14 January 2022 (UTC)

Template-protected edit request on 14 January 2022

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

Change: minor fix, wikitable tablerow |- for |FlashPt= must start at newline.

Test: Template:Chembox/testcases (set) § Hazards ordering; article DDT.

DePiep (talk) 03:40, 14 January 2022 (UTC)

 Done. P.I. Ellsworth - ed. ^put'r there 05:08, 14 January 2022 (UTC)

Nomination of Caffeine (data page) for deletion

A discussion is taking place as to whether the article Caffeine (data page) is suitable for inclusion in Wikipedia according to Wikipedia's policies and guidelines or whether it should be deleted.

The article will be discussed at Wikipedia:Articles for deletion/Caffeine (data page) until a consensus is reached, and anyone, including you, is welcome to contribute to the discussion. The nomination will explain the policies and guidelines which are of concern. The discussion focuses on high-quality evidence and our policies and guidelines.

Users may edit the article during the discussion, including to improve the article to address concerns raised in the discussion. However, do not remove the article-for-deletion notice from the top of the article.

DePiep (talk) 14:05, 14 January 2022 (UTC)

Title not showing?

By default the title of the chembox is the name of the article (as in Magnesium chloride), however I've just realized it doesn't always shows and has to be entered manually (as in Lithium aluminium hydride, old version where the title wasn't manually added [13]), is it a known bug?

Regards, --Aariuser (talk) 13:35, 19 January 2022 (UTC)

@Aariuser: good observation! Appears to happen when |Name=<blank> (so, Name (=overwrite title) parameter is present & empty). Will take a look for the solution. -DePiep (talk) 13:48, 19 January 2022 (UTC)

@DePiep: Makes sense! When editing using the visual editor there's no difference between the undefinied patrameter and the parameter = "" so I didn't see that, thank you! Regards, --Aariuser (talk) 13:55, 19 January 2022 (UTC)

It's a bug in the template, not editor's error :-) -DePiep (talk) 13:59, 19 January 2022 (UTC)

•  Done User:Aariuser looks solved, pls come back if something is strange. Thanks for the report. -DePiep (talk) 10:33, 20 January 2022 (UTC)

Template-protected edit request on 19 January 2022

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

Change: bugfix, |Name=<blank> would hide {{PAGENAME}} (infobox has no title) N. Changed if-logic.

Test: see Template:Chembox/testcases4 § Name. DePiep (talk) 14:07, 19 January 2022 (UTC)

 Done. P.I. Ellsworth - ed. ^put'r there 10:30, 20 January 2022 (UTC)

CAS Common Chemistry links broken from CAS registry nos.

Hello - I notice that the new version of the Chembox no longer includes links in the CAS Registry numbers. These are used as validation of CAS numbers through use of the CAS Common Chemistry website. These CAS numbers are very important for many chemists (I use them as part of my work regularly), and if we lose the authenticity of these numbers it will greatly undermine the authority of Wikipedia chemicals pages. Is there some way the links can be included again? They follow a simple URL pattern - for example, for anethole we should have CAS number [104-46-1] linking to https://commonchemistry.cas.org/detail?cas_rn=104-46-1. Walkerma (talk) 03:59, 25 January 2022 (UTC)

Walkerma Thanks for this report! It appears that a user/sandbox was introduced into the live code. Will be undone. ​ -DePiep (talk) 06:42, 25 January 2022 (UTC)

DePiep Excellent - thank you! (I also note that the expanded Common Chemistry site does have a separate entry for [4180-23-8], as trans-anethole.) Walkerma (talk) 07:14, 25 January 2022 (UTC)

Adding that one is regular editing, way below my level ;-) ;-) Would you need help with that? Like using indexes? -DePiep (talk) 07:25, 25 January 2022 (UTC)

It is trans as standard, cis is 104-46-1. --Project Osprey (talk) 11:33, 25 January 2022 (UTC)

@DePiep:, @Project Osprey: - thanks. Yes, the trans isomer is [4180-23-8], and [104-46-1] is actually the unspecified isomer, so I've inserted both with an explanation. Osprey, I think you're right that the trans is the usual natural form - I have my class do a lab where they isolate it from anise and it looks like pretty much pure trans. I didn't include [25679-28-1] which is in fact the cis isomer - see https://commonchemistry.cas.org/detail?cas_rn=25679-28-1 - I hope that was the correct call. Cheers, Walkerma (talk) 05:32, 28 January 2022 (UTC)

I've added to that. Before my wiki days I would never have questioned a CAS number, but now I know that to be an occasional mess. --Project Osprey (talk) 11:12, 28 January 2022 (UTC)

@Walkerma: As discussed at Template talk:Chembox CASNo/format#Unlinking commonchemistry based on Wikidata, this edit was introduced to unlink CAS numbers with a broken link. The method introduced works fine in that respect. However, in certain cases correct links are suppressed, too, unfortunately. This can be solved by adding the CommonChemistry link to the Wikidata item. --Leyo 22:24, 14 February 2022 (UTC)

What have I done wrong here

I fixed and error at Template:Chembox Properties/doc/parameter list were a missing set of of {{Solvent 6}} parameters causes the two lists to be unaligned - but now they're still unaligned and its because they're different heights. No idea what I've done there. Project Osprey (talk) 12:59, 1 July 2022 (UTC)

It was irregular beforehand. Fixed. -DePiep (talk) 13:53, 1 July 2022 (UTC)

_Ref on FlashPt

Resolved

 – ping @Graeme Bartlett:

-DePiep (talk) 05:52, 9 July 2022 (UTC)

It has been brought to my attention that using FlashPt_Ref on FlashPt (without C F or K) results in a space between the value and the reference, not how it is supposed to be. Can we remove the spacing? I see in Template:Chembox Hazards that a space using & # 20 is added to FlashPt: (and AutoignitionPt as well)

|temp_text={{{FlashPt|}}} |temp_text={{{AutoignitionPt|}}}

(not rendering as it appears in the original so look at source here) but why is it added? Graeme Bartlett (talk) 22:17, 3 April 2022 (UTC)

It's a bug. Working on this. Four temperatures are affected: |FlashPt, AutoignitionPt, MeltingPt, BoilingPt=. -DePiep (talk) 17:27, 22 June 2022 (UTC)

Template-protected edit request on 22 June 2022 (2)

Please replace all code in souce with code from /sandbox:

1. {{Chembox CalcTemperatures}} ← {{Chembox CalcTemperatures/sandbox}} (diff)
2. {{Chembox Properties}} ← {{Chembox Properties/sandbox}} (diff)
3. {{Chembox Hazards}} ← {{Chembox Hazards/sandbox}} (diff)

Change: bugfix (report). In situation

|MeltingPt=foo|MeltingPt_ref=<ref>{{cite source|...}}</ref> a space is added before the reference:

→foo N

Test: see /testcases9: Template:Chembox/testcases9 § FlashPt and ref. Currently tests may be defunct because of /sandbox removals for going live. During the changeover (seconds) of the three, no unacceptable or broken situation expected (especially not when in this order 1-2-3).

DePiep (talk) 17:55, 22 June 2022 (UTC)

 Done * Pppery * _{it has begun...} 15:23, 8 July 2022 (UTC)

References

Thermal conductivity and electrical resistivity?

I request to add these fields. Thank you. AXONOV (talk) ⚑ 10:38, 19 June 2022 (UTC)

In section {{Chembox Properties}} there is

|ThermalConductivity=. Does that serve?

electrical resistivity could be added (in Properties).

Remarks anyone? -DePiep (talk) 16:49, 19 June 2022 (UTC)

@DePiep: Does that serve? Yup, it does. We still need |ElectricalResistivity= one. Cheers. AXONOV (talk) ⚑ 19:07, 21 June 2022 (UTC)

• Y Added |ElectricalResistivity= in sandbox. See {{../testcases9#Electrical Resistivity}}.

Positioned right below Isoelectric point, ok? (more in example)

FYI: {{Infobox element}} already has this parameter, eg Aluminium.

@Alexander Davronov: If OK, we'll add it to {{Chembox}}. -DePiep (talk) 04:15, 22 June 2022 (UTC)

@DePiep: Oh wait, may be you consider to add it to the {{Chembox Properties}} instaed? I think it would be more appropriate. AXONOV (talk) ⚑ 15:25, 22 June 2022 (UTC)

It is in Properties! See {{../testcases}}. Will get it live. -DePiep (talk) 15:55, 22 June 2022 (UTC)

 Done Alexander_Davronov. -DePiep (talk) 17:29, 22 June 2022 (UTC)

Thnx. AXONOV (talk) ⚑ 22:08, 22 June 2022 (UTC)

Thnx. AXONOV (talk) ⚑ 22:08, 22 June 2022 (UTC)

Thnx. AXONOV (talk) ⚑ 22:08, 22 June 2022 (UTC)

• Alexander_Davronov: |ElectricalResistivity= was added, but it is not used at all... Any prospects? -DePiep (talk) 10:22, 25 July 2022 (UTC)

  @DePiep: Give a bit more time! I can't edit billions of articles obviously. AXONOV (talk) ⚑ 10:24, 25 July 2022 (UTC)

  :-) DePiep (talk) 10:35, 25 July 2022 (UTC)

  @DePiep: I've added it to at least one article! Checkout. AXONOV (talk) ⚑ 10:46, 25 July 2022 (UTC)

  Now we can move ahead. DePiep (talk) 10:54, 25 July 2022 (UTC)

Template-protected edit request on 22 June 2022

• Please replace all code in {{Chembox Properties}} with {{Chembox Properties/sandbox}} (diff).

Change: Added |ElectricalResistivity= per § Thermal conductivity and electrical resistivity? talk request.

Test: See {{Chembox/testcases9#Electrical_Resistivity}}.

DePiep (talk) 16:01, 22 June 2022 (UTC)

 Done. P.I. Ellsworth , ed. ^put'r there 17:09, 22 June 2022 (UTC)

Discrepancies

When a discrepancy comes to light, between data appearing in the infobox and data cited in the text (both assumed tied to reputable sources), until they are reconciled, if they can be, the datum appearing in the infobox should bear a superscripted citation (standard inline citation), so that incoming editors can go quickly and directly to the source of the infobox information. For instance, if an article states a melting point from a reliable source, in text, that does not match the m.p. given in the infobox, if the m.p. in the infobox does not have the specific citation from which that datum was drawn, the problem cannot be reviewed and resolved. (Citing 10 possible sources of the information — rather than the 1 source from which the datum was actually taken — hinders rather than helps editors from verifying information, in keeping with WP:VERIFY.) 2601:246:C700:14C:686D:F2B1:A446:EB9 (talk) 20:46, 28 July 2022 (UTC)

This problem can be solved by moving data from an article body to the chembox. One can also use {{efn}} combined {{notelist}} to collect a bunch citations into a group. E.g.:

--AXONOV (talk) ⚑ 08:13, 3 August 2022 (UTC)

In general: all data in {{Chembox}} can have regular references (<ref> .. </ref>). Please notify if you see parameters with problems in this.

Then, if values between infobox and article-body conflict, regular resolving is open. For example, inline tags like {{Contradict-inline}} and {{Disputed inline}} etc can be added.

Does this solve the question? -DePiep (talk) 08:24, 3 August 2022 (UTC)

Relative permittivity

Relative permittivity is a property of many chemical compounds and elements that characterize an electric field permittivity at different states of the compound. Are we fine with adding an |relativePermittivity= param to {{Chembox Properties}} sub-template? I propose to discuss this. AXONOV (talk) ⚑ 10:06, 25 July 2022 (UTC)

I am waiting for involved-editors support for inclusion, or a serious list of substances potentially using this parameter. DePiep (talk) 12:48, 18 August 2022 (UTC)

Add "Found in taxon"-list (proposal)

Over at WT:CHEMICALS: "found_in_taxon"-statement from Wikidata is a discussion to add this list. Please join there. -DePiep (talk) 12:55, 21 September 2022 (UTC)

Extra blank paragraph

Carbon dioxide has a blank paragraph between the hatnote and the lead section. Judging from its styles, it seems to be generated by {{chembox}}. Please fix. Hairy Dude (talk) 00:15, 28 November 2022 (UTC)

I don't see any extra paragraph. Can not reproduce. Neither in mobile view. ExpandTemplates the top does show extra lines & adds category in top & nowiki tag & newlines, none by {{Chembox}} AFAIK. Could you specify? Does it happen in other pages? DePiep (talk) 07:48, 28 November 2022 (UTC)

Chembox: adding AITS spectral database external link (SDBS)

• See Wikipedia talk:WikiProject Chemistry § Linking Chembox to spectroscopic data on the AITS database (AITS: SDBS database external link). -DePiep (talk) 11:42, 19 January 2023 (UTC)

UNII links

Today I notice UNII links from our chemboxes not working. eg for silver stearate the link is https://fdasis.nlm.nih.gov/srs/srsdirect.jsp?regno=4H6PCL92ZN but this gets site is unavailable for me. Perhaps this is temporary. Nut PubChem now links to a different site: https://gsrs.ncats.nih.gov/ginas/app/beta/substances/4H6PCL92ZN Graeme Bartlett (talk) 03:05, 8 February 2023 (UTC)

Here site https://fdasis.nlm.nih.gov/ says "no connection" too.

Is the GSRS site a confirmed/RS alternative? ( https://ncats.nih.gov/expertise/preclinical/gsrs Global Substance Registration System GSRS )

Q1: Looks like a different database. Should it better be listed under its own name? (pls propose/advocate someone)

Q2: is UNII used as identifier key, not chem informnmation by itself? IOW, the (nowdead) link is a number-cinfirming source, not an external database? Say, like the CAS RN external link. DePiep (talk) 05:31, 8 February 2023 (UTC)

Note: I am trying to contact User:Fswitzer4 about this. Graeme Bartlett (talk) 22:54, 12 February 2023 (UTC)

NLM stopped hosting the site a year ago and it appears they recently stopped autoforwarding. The replacement site is on PrecisionFDA. Here is the silver stearate example https://precision.fda.gov/uniisearch/srs/unii/4H6PCL92ZN Fswitzer4 (talk) 13:28, 13 February 2023 (UTC)

Template:Infobox drug links to a yet a different url eg https://precision.fda.gov/uniisearch/srs/unii/RE0V0T1ES0 . Vis Template:Infobox drug/formatUNII. Perhaps we can change chembox to use this url pattern. Graeme Bartlett (talk) 23:03, 12 February 2023 (UTC)

• Y edit request below, to use precision.fda.gov all right. Somehow {{Infobox drug}} was updated already a year ago [14] ?! Good we didn't pursue GSRS then. Thanks for the input. -DePiep (talk) 14:59, 13 February 2023 (UTC)

Template-protected edit request on 13 February 2023

Please replace all code in {{Chembox UNII/format}} with all of {{Chembox UNII/format/sandbox}} (diff).

Change: update external link target, per based talk request § UNII links.

Tested: (1) Template:Chembox/testcases2#UNII testcases. (2) compare {{Infobox drug}} (already updated similarly Feb2022).

Note: only one template to update. DePiep (talk) 14:54, 13 February 2023 (UTC)

 Completed, and thank you very much! P.I. Ellsworth , ed. ^{put'er there} 16:36, 13 February 2023 (UTC)

Adding Cambridge Structural Database identifiers to Chembox

See § Adding Cambridge Structural Database identifiers to Chembox (CSD). -DePiep (talk) 17:08, 21 February 2023 (UTC)

No GHS hazards classifications

Category:GHS errors currently displays the following text in its description:

Currently (December 2021), articles are listed that have value |1=- to state: No GHS hazards classifications.

They are categorised "error" during development (please ignore this).

However, it seems that the editor, DePiep (talk · contribs), responsible for this message and the work associated with it has been banned indefinitely. It's been over a year and no-one else appears to have taken over the work, unless I'm mistaken.

Since Category:GHS errors has a handful of pages which use |1=-, what should be done about them? Should we simply remove the hyphens? Doing so causes the entire Hazards section to not be displayed, since it's otherwise blank. – Scyrme (talk) 18:48, 31 May 2023 (UTC)

In the case of {{HPhrases|-}}, a short note such as no H phrases should appear. See e.g. Naphthol Green B vs. de:Naphtholgrün B --Leyo 21:45, 31 May 2023 (UTC)

Seems sensible to me. What needs to be done to implement that? – Scyrme (talk) 21:59, 31 May 2023 (UTC)

I guess that this would need to be implemented in Module:GHS phrases or Module:GHS phrases/data. --Leyo 07:28, 1 June 2023 (UTC)

The templates appear to only check for unknown parameters, so, yes, it probably is a change to Module:GHS phrases. Module:GHS phrases/data controls whether a phrase is recognised and the tooltip note that appears if it is recognised. Unless I'm mistaken, it doesn't determine how the phrase itself is displayed. I assume Module:GHS phrases does that, but I don't have enough experience to figure out what would need to be changed. It's clearly handled somewhere since the template automatically displays "P" and "H" before the numbers even if the editor omits them when listing them in an article.

Unfortunately, the German Wikipedia's implementation seems to be very different, so I don't think simply copying their solution over is feasible. (Said solutions seems to be encoded here, or at least part of it is.)

@Leyo: Do you have experience with Lua modules? – Scyrme (talk) 20:05, 1 June 2023 (UTC)

Unfortunately not at all. --Leyo 08:00, 2 June 2023 (UTC)

@MSGJ: Hello again! If you're not too busy, would you take a look at this? – Scyrme (talk) 19:50, 12 June 2023 (UTC)

Yes, pretty busy with Module:WikiProject banner and I wouldn't know where to start with this module. Is the module behaving properly but you don't know how ti fix the articles? Or are the articles okay but the module is producing spurious errors? — Martin (MSGJ · talk) 21:01, 12 June 2023 (UTC)

@MSGJ: tl;dr: Something in Module:GHS phrases needs to be changed so the template will display a text when a hyphen is used as an input. It currently displays nothing when the hyphen is used. The articles are okay, the module isn't working as intended.

If you're too busy, I'd appreciate if you could suggest someone who might know enough about modules to help.

Module:GHS phrases/data controls the tooltip, but I don't think it controls the actual text displayed to readers; I think I can sort out what needs to be done in /data; the main module is where I'm stuck. It's probably not that complicated, but I don't have enough experience interpreting the code. – Scyrme (talk) 21:51, 12 June 2023 (UTC)

Please explain as clearly as possible what should be displayed when a hyphen is used. No promises when I will be able to look at this though. You could also try WP:VPT or WP:LUA — Martin (MSGJ · talk) 08:25, 13 June 2023 (UTC)

If |1=- is used {{GHS phrases}} should display no GHS classifications. – Scyrme (talk) 18:08, 13 June 2023 (UTC)

False positives?

When I updated the GHS for Neophyl chloride using the details from PubChem a number of predefined combinations weren't recognised and are categorised as P-phrase errors. The unrecognised combinations are described in this list.

Are they false positives? Or have I neglected something at Neophyl chloride? (If these are false positives, there are likely many others in the tracking category; the predefined combinations recognised by the template/module might need to be systematically updated.) – Scyrme (talk) 23:39, 30 May 2023 (UTC)

It is not just your edits, I have been adding such entries too. They are not false. We are missing them from the Wikipedia listing. Graeme Bartlett (talk) 02:03, 31 May 2023 (UTC)

A false positive means they are falsely being recognised as errors; if the P-phrases are correct and Wikipedia needs to be updated, then they are false positives. – Scyrme (talk) 16:35, 31 May 2023 (UTC)

To me, "not false" means "the GHS is correct" rather than "not a false-positive detection of mistake". This conversion is a nest of double- and triple-negatives:) I have occasionally looked at updating the template checks, and generally gave up because it's such a spaghetti and so many duplicative parts. DMacks (talk) 16:44, 31 May 2023 (UTC)

Regardless, I've attempted an update to Module:GHS phrases/data and the wrongly categorised pages appear to be clearing out. – Scyrme (talk) 17:36, 31 May 2023 (UTC)

Alright, looks like it's done clearing. Category:GHS errors has gone from over 100 down to just 11. (Not counting the subcategory, Category:GHS warnings. That's unchanged.)

The remaining entries appear to pertain to |1=-, which is mentioned in the category description ("Currently (December 2021), articles are listed that... please ignore this"). – Scyrme (talk) 18:21, 31 May 2023 (UTC)

Category:GHS errors is now cleared, except for those articles using a hyphen. This includes the subcateogory, which is now empty. Thanks to whoever sorted out the last remaining ones in Category:GHS warnings before I got around to it. – Scyrme (talk) 00:22, 16 June 2023 (UTC)

Looks like LaundryPizza03 went ahead and removed the hyphens on 18 June. – Scyrme (talk) 10:26, 18 July 2023 (UTC)

Template-protected edit request on 15 August 2023

Add legal_BR and legal_BR_comment to Template:Chembox Pharmacology

It's already present in Template:Infobox drug/legal status and Template:Chembox Legal_status

-- Arthurfragoso (talk) 17:42, 15 August 2023 (UTC)

Drugs that I want to set the status: (so its easier to find them later, otherwise I might forget)

• Thebaine -> legal_BR = A1
• Oripavine -> legal_BR = A1
• 3,4-Methylenedioxyphenylpropan-2-one -> legal_BR = D1
• 4-Aminopyridine -> legal_BR = D1
• Chloral hydrate -> legal_BR = C1

-- Arthurfragoso (talk) 06:32, 16 August 2023 (UTC)

 Done Using Legal_BR and Legal_BR_comment for consistency with other parameters. SWinxy (talk) 21:09, 16 August 2023 (UTC)

Thanks, but it partially works.

When I click in preview, It works and shows up in the chembox, but it also shows up a red message saying: Error in template * unknown parameter name (Template:Chembox Pharmacology): "Legal_BR; Legal_BR_comment" (See parameter list). This message only shows in Preview, it will not show after Publish changes.

I tested in the sandbox, and there are two more places in the code that needs to include the parameters: just at the top in the #if: and a bit bellow between "templatepar" and "END HEADERBAR" -- Arthurfragoso (talk) 06:18, 18 August 2023 (UTC)

 Done * Pppery * _{it has begun...} 23:07, 26 August 2023 (UTC)