Template talk:Chembox/Archive 9

Apologies, but how can
...a generic list of infobox sources, non-annotated as to which specific sources are used for which specific data fields, be acceptable as a means of verifiability here? This seems a further example of "just trust us" writing, and it is not encyclopedic. Is we cannot place the name of the author at the head of the article, so her/his credibility can be questioned, we have to be able to establish content credibility via the verifiability of the sources of the scientific information. Tens of data values, and a generic list of sources… what, we expect a reader to guess, or to look into each source, to try to source/verify the one datum of interest? No, we expect him to trust us about our provision of the data. And to this I say "No. One thousand times, No." 71.239.87.100 (talk) 03:12, 1 May 2015 (UTC) Leprof 7272 (talk) 03:20, 1 May 2015 (UTC)
 * What do you mean? I'm pretty sure it's possible to put references in the infobox directly next to the parameter. I've done it in ethanol. Sizeofint (talk) 03:25, 1 May 2015 (UTC)
 * That is the ideal I seek. But have a look at the info box at right.


 * Only the pKa datum has a source. (Brava/o to that editor.) Clicking on the link at the bottom, for sources. takes one to the generic list of sources. Is this an example of sloppiness on the part of the original editor (to not include sources in the box)? What is the expectation we impose when we review? My tendency would be to blank out unsourced data, as it is the responsibility of the originating editor to source their work. You can imagine my popularity...


 * Leprof 7272 (talk) 03:48, 1 May 2015 (UTC)
 * Please study WP:VERIFY and all its related guidelines first. Then explain again (as in: prove) why you would blank those fields. Also, you might include why the bottom reference link would not do as a reference. Until you have convinced others, better do not not blank those fields. Not because you might become unpopular (how encyclopedic is that btw?), but because it might be considered vandalism very easily. -DePiep (talk) 07:58, 1 May 2015 (UTC)
 * Part of the reason for this that a lot of our editors don't have good access to literature; so when they make a Chembox a lot of the simple data (mpt, bpt etc) is often scraped from the Sigma Aldrich website (or similar). I agree that this use of un-referenced data is not ideal and should be discouraged now that we have things like RSC-Gold etc, but I also don't see a simple fix regarding the historic backlog. There are around 9700 pages with a chembox (including drugbox I think we're up to ~13K) referencing all the values contained in those boxes is the work of years (although I suppose you could start with the top 100). There's also the question of what to do when various different values exist within the literature, do we use multiple citations? At what point does an encyclopedia become a chemical database, and should it? --Project Osprey (talk) 09:14, 1 May 2015 (UTC)

. Basically, you're right, the data should be referenced. Problem there is however threefold. First is to find proper sources who have done the fact-checking for that value (and not fact checking in 'they report a value of 100°C, that sounds right', I mean fact checking in 'we independently made the compound, and determined the boiling point') - you will find that most sources stating physical data are basically primary and, obviously, not SPS. The only 'secondary' data there is (2nd problem) is by conglomeration of data - for quite some chemboxes the compound has been made independently, and most sources have distilled it and determined a boiling point (and reported that) - the fact that all sources say the same (and you will find a lot of them in the 'Infobox references') is evidence that the value reported in our chembox is 'correct'. However, that is original research. The third thing is that 'any material challenged or likely to be challenged must be attributed to a reliable, published source' - that challenging either requires a leap of faith: 'it says a boiling point of 134.1°C, I say it is not' (i.e., without giving a reason why it is not, or what it would be - a kind of 'who says that it is 134.1°C?'), where we would say, 'we know it is OR, but look, most (primary) sources state a boiling point between 133 and 135, so unless you can show sources that show another value, you're not really challenging this one), or the challenge is indeed giving a reference showing it is wrong because it gives a completely different value (but note that that source likely is also a primary source).

In short, I agree that the fields should be referenced where properly possible (also to aid the reader to more information regarding that datapoint) and reasonable (if there are 50 primary sources showing a boiling point of ~134.1 ..), but enforced referencing or enforced removal when unreferenced is only needed when either properly challenged ('it can't be right because '). --Dirk Beetstra T C 05:14, 5 May 2015 (UTC)
 * Please don't include refences in tempalte fields meant for data. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 08:49, 7 May 2015 (UTC)
 * Why? --Project Osprey (talk) 08:55, 7 May 2015 (UTC)
 * That breaks (machine) readability of the specific field. Some of them however have a dedicated 'reference' field with them (IIRC, MeltingPt has MeltingPt_Note), where the actual field is used for the data, and the note-field for .. notes / references.  --Dirk Beetstra T  C 10:54, 7 May 2015 (UTC)
 * Most fields aren't machine readable anyway. I know that's being worked on but, but there's already so much information that will be difficult to parse - and will likely need special work-arounds to be coded - I wouldn't have though that adding an extra line to deal with tags would have been a big deal. --Project Osprey (talk) 12:32, 7 May 2015 (UTC)


 * re primary topic: as others have described, there is no reason to blanket delete unsourced data. This is the way wiki works, and it is not WP:BLP critical.
 * re the secondary topic "&lt;ref> in data field".
 * As Beetstra hinted, the temperatures (melt, boil, flash, autoignite) have dedicated fields like MeltingPt_ref to add references nicely. This is required because temperature values are calculated by  and a ref would spoil the numeric input and/or ref position. MeltingPt_notes is available for a suffix too in the data row, but with a space added.
 * For the indexed identifiers there is CASNo_Comment for refs. Quite unfortunately, historically CASNo_Ref is used for the validation bot only :-(
 * Most other data entries are free text, and are mostly used to enter data like prefix, number, SI unit, &lt;ref>, notes, 2nd value (R, S), etc as is needed.
 * Together, I think this shows that adding sources can be done correctly (sometimes complicated, I agree).
 * Further, on the idea of separating the references for all ~100 data rows (into a dedicated parameter). This is template-technically conceivable but would expand documentation even more, and still does not solve all the need for free text input e.g. for R, S variants and notes. Also, in the same area of big-change there is to be considered: going Lua, merge options with, use indexes more systematically, use wikidata, use standard . With this, adding an already existing option :-) should not have priority. Even more, I think the argument "machine-readibility" is not weighing because of wikidata and because that is not the primary target of a wikipage. -DePiep (talk) 20:03, 8 May 2015 (UTC)
 * The current 'CasNo_Ref' should be renamed to 'CasNo_Check' - it was indeed a wrong choice made at the startup of that. Unfortunately, a request to have that all changed over was met with resistance.  For the identifiers, it is not a problem (they actually don't need a reference, they are primary referenced by themselves) but it is going to be a problem later that needs to be solved sooner rather than later.
 * Machine readability is not a primary target, indeed, but there is no problem with being prepared for that, or providing that service. If ever (I hope not) the wikidata is to be pulled into infoboxes, the same problem will occur: WikiData will store '100°C', not '100°C&lt;ref>....&lt;/ref>', and that update would hence then wipe out from visibility all our references.  Moreover, some of the data is immutable (the boiling point of water will always be 100°C), whereas the references that state that may change (and that is a CheMoBot machine-readability-issue).
 * Documentation does not have to grow massively - the list of all fields will, but the documentation become shorter because 'for every field there is a 'field_Ref' which can be used for references'. --Dirk Beetstra T  C 03:30, 11 May 2015 (UTC)
 * My reply was to the secondary topic (1. "should a ref be added?", 2. "can a ref be added?"), saying that it can. If y'all don't mind, I skip the tertiary topic of possible parameter name changes here. And about Unfortunately, a request to have that all changed over was met with resistance: At that moment 35 interrelated {Chembox} templates were in sandbox changes & tests. It would be very unwise to add another big edit process. Strange that you don't remember that there was a reason, simply calling it "resistance" instead of like "not viable". -DePiep (talk) 11:23, 11 May 2015 (UTC)
 * It is just another case like the above case of changing something while you are busy with it. Lets just agree that we disagree there, DePiep.  --Dirk Beetstra T  C 05:57, 12 May 2015 (UTC)
 * In this point, I don't think we disagree :-). I was about the wording here only, since we both understood back then to better not-interfere the edits. -DePiep (talk) 09:45, 12 May 2015 (UTC)
 * I was saying that we disagree there, I did not agree to not 'interfere' with the your edits - I still disagree that that would impose problems on your editing. --Dirk Beetstra T  C 11:03, 12 May 2015 (UTC)
 * Oh. -DePiep (talk) 17:04, 12 May 2015 (UTC)

Molar mass revisited
For Drugbox, I am building an automated molar mass calculator, using the molecular formula input (like has/does now). Compared to, some design changes and improvements are considered. Once stable, the aim is to replace the one too to have all features shared. See Drugbox talkpage. -DePiep (talk) 17:54, 12 May 2015 (UTC)

Proposal to change molecular mass calculation
I propose to change the molecular mass calculation. The values used may be outdated, as there are no checks (hint: 'Uub' is used while it is named Cn since 2009!). The new form uses the new template Chem molar mass as subtemplate. This setup is also used by Drugbox (proposed) so that this wiki uses one single form of calculation. See that templates documentation for sources used (mainly CIAAW). Calculation only can be performed when the molecular formula is entered by chemical symbol, like, not by hardcoded Formula.

Another change is that an editor can overwrite the calculated value by MolarMass, so the editor is in control (in the old situation the calculation would be shown when available). These articles are listed in for a maintenance check: is the overwriting intentional, or can it be removed to have the calculated value showing?

Some related parameters are added to control presentation, also for Formula. The new set is: Demos and tests are at this test page.
 * C=|H=|O= &tc.
 * Formula =
 * Formula_ref =
 * Formula_Comment =
 * MolarMassRound =
 * MolarMassUnit =
 * MolarMass =
 * MolarMass_ref =
 * MolarMass_Comment =

Changes are: using more recent and sourced values, more control for the editor, single place of calculation (shared with ), feedback for maintenance.

Any comments or questions? -DePiep (talk) 13:56, 28 May 2015 (UTC)
 * Looks good I think, but I do not like the references for formulas and molar mass. I really cant see why they are needed. MolarMassRound: The name isnt very self-explaining, but I guess from you previous messages at module talk:math that its about the precision. Why Uub hasnt been changed - the longest isotope lives for a few minutes and we do not have any article about its compounds. MolarMass are not new - its already in the old version of the chembox - anything new about it? Template:Chembox_Elements and sandbox version; "molecular formular" should be changed to chemical formula like the output from |Formula Christian75 (talk) 21:36, 28 May 2015 (UTC)
 * Yes, a useful and careful post. I'll reply extensively later on, adding demos for ref and comment parameters. The 'new' set of parameters I listed are just those "useful tomorrow", not the factual available ones. (that is, they are those useful & published, skipping those deprecated). My aim is that the editor can control the article page. -DePiep (talk) 23:28, 28 May 2015 (UTC)
 * re. I've added parameters _ref and _Comment to allow output like: . Since the formula resp. mass itself is structured data (in either input option: fixed or constructed from symbols), we can not have &lt;ref> code in its input, nor can we add free comment text. It is up to the editor to use this, I don't see the need to forbid (make impossible) such input beforehand.
 * I wrote "the new set is..." to introduce a complete set of params, not to say that all are new. Formula, MolarMass, MolarMassRound and the symbols are existing parameters. No infobox edits are needed to have this mass calculation functioning, it's just supplementary parameters that are added.
 * MolarMassRound rounds the calculated number to decimals (default=2 decimals, as you noted earlier), unchanged. It is already described in Chem molar mass documentation, and the infoboxes doc should be updated.
 * I mentioned Uub=Cn only to show that the old list was not updated/checked that well. I did not look for other differences, as I took the numbers straight from the sources (see subtemplate documentation).
 * Do you propose to change the lefthand visible text (label) from "Molecular formula" into "Chemical formula"? (I do not understand 'like the output from |Formula'; that output is the input Formula usually a formula like ). -DePiep (talk) 10:27, 29 May 2015 (UTC)
 * The output from |formula (in the infobox chemical) from Chembox_Formula is | Chemical formula
 * A label and a value. So yes I suggest it should give the same label for both |formula and the |H=|He= notation ... Christian75 (talk) 12:33, 29 May 2015 (UTC)
 * Good catch, hadn't even noticed this diff... In the sandbox they are the same. It now says Chemical formula for both. -DePiep (talk) 13:06, 29 May 2015 (UTC)
 * This detail: should the LH label be Chemical formula or Molecular formula? -DePiep (talk) 20:07, 29 May 2015 (UTC)
 * I would say Chemical formula, more generally correct for non-molecular materials. Hmm, making the hand-calculated molarmass overwrite may result in a lot of incorrect data coming in, this maintenance should be done rather fast.  --Dirk Beetstra T  C 03:42, 31 May 2015 (UTC)
 * Chemical formula it will be. Param name not changed though. Plain thinking: those 'hand-calculated' masses are already wrong today, then! Most will be by sincere article editors, no havoc I expect. Anyway, articles with both calc & handcalc values will be categorised for maintenance. -DePiep (talk) 23:11, 2 June 2015 (UTC)
 * I would say Chemical formula, more generally correct for non-molecular materials. Hmm, making the hand-calculated molarmass overwrite may result in a lot of incorrect data coming in, this maintenance should be done rather fast.  --Dirk Beetstra T  C 03:42, 31 May 2015 (UTC)
 * Chemical formula it will be. Param name not changed though. Plain thinking: those 'hand-calculated' masses are already wrong today, then! Most will be by sincere article editors, no havoc I expect. Anyway, articles with both calc & handcalc values will be categorised for maintenance. -DePiep (talk) 23:11, 2 June 2015 (UTC)

Template-protected edit request on 31 May 2015: Plurals and periods
The text on the template page has the words "Except where noted otherwise, data is given for materials in their standard state (at 25 °C (77 °F), 100 kPa)". Two technical requests: 1.) the correct plural verb "are" with the word "data" ("...data are given for materials...") and 2.) a period at the end of the sentence. Thanks!

KDS 4444 Talk  13:08, 31 May 2015 (UTC)
 * Though both are correct, "are" is more common in scientific writing, so whatever, I guess. Alakzi (talk) 14:27, 31 May 2015 (UTC)
 * See Data: "This word is more often used as an uncountable noun with a singular verb than as a plural noun with singular datum". The ending period was omitted for being a WP:caption. Interestingly, the edits that could stay are those two not asked for here. -DePiep (talk) 19:11, 31 May 2015 (UTC)
 * It's not a sentence fragment, so it should end in a full stop. See WP:CAPFRAG. Alakzi (talk) 19:26, 31 May 2015 (UTC)
 * 'Data' is here practically always pointing to multiple different values, so though it would be correct as a singular, it practically always is pointing to a plural. I think as well that this should be implemented, and I will do so if there are no reasoned objections.  --Dirk Beetstra T  C 06:09, 2 June 2015 (UTC)
 * I implemented it when I marked the request as answered. Alakzi (talk) 10:11, 2 June 2015 (UTC)
 * re Caption-period: clearly the two MOS links can contradict (As they do in this situation). That leaves the data issue. As Alakzi notes in the first response, it is up for dispute & did open that dispute (though I find 'whatever' not a convincing argument). So the editor declares it disputed, enters argument, and then concludes themselves. That is not waht pe request is for. Either one concludes completeness & edits, or one starts the discussion (with or without involvement). Not both. -DePiep (talk) 11:07, 2 June 2015 (UTC)
 * What parts of the MOS are contradictory? Alakzi (talk) 11:23, 2 June 2015 (UTC)
 * Those who can contradict you ask, I presume? Those two we both liked to. By the way, again you are skipping the core point. -DePiep (talk) 21:57, 2 June 2015 (UTC)
 * WP:CAPFRAG is a section of WP:CAPTIONS; it is the only place where the use of full stops is explained. I don't care if it says "is" or "are", personally, and I wouldn't object if anybody were to revert. Alakzi (talk) 22:06, 2 June 2015 (UTC)
 * See my 11:07 post. What is the completement of your reply? -DePiep (talk) 22:33, 2 June 2015 (UTC)
 * WP:TPROT's purpose is not to obstruct copy-editing. In cases such as this, the edit request is but a formality; if an objection is subsequently raised, the edit can be undone as it normally would be. Would you like me to revert the change to the plural? Alakzi (talk) 23:00, 2 June 2015 (UTC)
 * Again: you yourself wrote #1 that it is not a formality. You made clear it is controversial. After that, #2 you should not have edited. (If I wanted a reversal, I could have done so myself. What I want is that you understand that you behaved duplicitly). -DePiep (talk) 23:43, 3 June 2015 (UTC)
 * I don't think I've done anything wrong here, but you can ask for a third opinion. Alakzi (talk) 23:30, 4 June 2015 (UTC)

Template-protected edit request on 4 June 2015
The code in this template that used to read  now reads. The result is the reference entered is not visible and produces reference errors. See the problem at Iron(II) sulfate.

StarryGrandma (talk) 05:08, 4 June 2015 (UTC)
 * The change was made by [ping!] in this edit. I don't understand the HTML comment "ref not bot", so hopefully DePiep can respond to this request. -- John of Reading (talk) 06:45, 4 June 2015 (UTC)
 * Researching. -DePiep (talk) 23:01, 4 June 2015 (UTC)
 * Found issue. Will fix in 24h. -DePiep (talk) 23:20, 4 June 2015 (UTC)
 * ✅. NFPA_Ref, NFPA_ref now both accepted. (The uc is deprecated because it is not like the other  CheMoBot parameters, lc preferred. However, deprecation process is stalled). -DePiep (talk) 06:58, 5 June 2015 (UTC)
 * Thanks. StarryGrandma (talk) 21:23, 6 June 2015 (UTC)

Template edits 7 June 2015

 * Molecular mass calculation
 * Calculation from molecular formula, now using new Chem molar mass with sourced atomic weights.
 * Request: Template_talk:Infobox_drug
 * Proposal finalised: Template_talk:Infobox_drug
 * Several parameters like rounding and ref added, following subtemplate documentation
 * Maintenance:


 * PLLR, pharmacology
 * For PLLR, added PLLR
 * Talk: Template_talk:Infobox_drug


 * EC number, identifiers
 * Merged input EINECS, EC-number, EC number into one value
 * Deprecate and abandon EINECSCASNO; Untouched: EU Index
 * Talk Wikipedia_talk:Chemical_infobox
 * Maintenance:


 * Safety data sheet - SDS
 * Change code to show both datapage and ExternalSDS input when available.
 * Add parameter Hazards_data_page for this SDS to overwrite an eventual link to.
 * Wording changed. Automated link to data page section  (sp).
 * Move data row 'Main hazards' to top (one up), because it says Main.
 * Talk: #Change_MSDS_to_SDS, details
 * Data pages are listed in (155 P)


 * LDLo, LCLo
 * Not yet done, discussion not finalised. Talk: Wikipedia_talk:Chemical_infobox


 * Maintenance categories removed
 * Talk: Wikipedia_talk:Chemical_infobox
 * To be deleted.
 * To be deleted.
 * To be deleted.


 * Code cleanup
 * Some internal code cleanup, no effects.


 * Alignment with
 * Topics molecular mass, PLLR, and SDS data page are treated similar in Infobox drug. -DePiep (talk) 23:22, 7 June 2015 (UTC)


 * Preparing. -DePiep (talk) 23:22, 7 June 2015 (UTC)
 * ✅ -DePiep (talk) 00:10, 8 June 2015 (UTC)

Discussion about data pages
A discussion was started at WP:Chemistry#Data_pages about what to do with data pages like Ammonia (data page) for Ammonia (more listed ). -DePiep (talk) 10:26, 8 June 2015 (UTC)

Adding PLLR (US, pregnancy) to Drugbox
I am proposing to add PLLR to. PLLR is the new US FDA drug labeling rule regarding pregnancy and more. Discussed at Infobox drug talk. -DePiep (talk) 22:54, 26 May 2015 (UTC)
 * And added to, parallel. -DePiep (talk) 11:40, 8 June 2015 (UTC)
 * ✅. See #Template edits 7 June 2015. -DePiep (talk) 11:40, 8 June 2015 (UTC)

Chembox structure additions

 * Useful link: Chembox/testcases11

in Template:Chembox Structure there seems to be parameters to describe the crystal structure. But some commonly published info has no parameters, The extra ones I want to use are the number of formulas per unit cell, commonly termed Z, and the unit cell volume V.  Also it would be good to have another field in case the temperature was not 25° or standard pressure. Also some materials can have different forms. So far I have repeated the template, but that is not the best solution. For the purposes of data extraction it would be good to have a reference field separate too. Graeme Bartlett (talk) 07:40, 4 June 2015 (UTC)
 * As long as we use this SectionN= structure, repetition is acceptable because it produces the right outcome. (When going to Infobox later this century, the change process must cover such situations). We can introduce indexes though, like we have with CASNo2, if deemed important.
 * Chembox Structure has a full example in the documentation. Any interesting example article(s)?
 * First throw, we can add these params:
 * UnitCellFormulas
 * UnitCellVolume
 * Better names possible? Does one have a common/standard unit (default)? Any other structure in the data we could use?


 * Then, we need wikilinks and labeltext for the lefthand sides (two new data rows).
 * For UnitCellFormulas: text="Number of formula". Link = Formula unit
 * For UnitCellVolume: text="Unit volume". Link to Crystal structure. (Atomic packing factor is not the same, but it uses this V).


 * As elsewhere in, ref and comment (freetext, unedited) can be added at the end:
 * Structure_ref, Structure_Comment
 * However, do you need these with every parameter? Or just once for the structure section? -DePiep (talk) 07:29, 5 June 2015 (UTC)
 * re myself: after second reading, it looks like the whole crystal structure section describes one single structure CrystalStruct. Always entered. We can add CrystalStruct_ref, CrystalStruct_Comment to that top data row then. -DePiep (talk) 07:34, 5 June 2015 (UTC)
 * That proposal looks OK. Replicating the sections sounds OK to me.One comment per section would be fine, and usually one reference will have everything. Sometime a reference will miss the number of formulas or unit cell volume or density.  Density can be calculated from the volume, molecular weight and formulas, but it is often published too.  But density appears elsewhere anyway. Often the theoretical density can be different to the measured, perhaps because of gaps, defects, inclusion of extra substances, such as solvent. My example is indium sulfate. Graeme Bartlett (talk) 23:24, 5 June 2015 (UTC)
 * So we can assume that CrystalStruct is always present in the ~1600 Chembox Structure pages.
 * Can you provide links for the two new data: "number of formulas per unit cell, commonly termed Z", and the "unit cell volume V"? That would be the lefthand link it the data row. At least, write a new article or section for them somewhere. If there is no wikilink available, it is questionable why we would mention that data at all.
 * btw, in indium sulfate I see: "Coordination geometry: 6 formula per cell". Isn't that what you asked for? -DePiep (talk) 13:14, 6 June 2015 (UTC)
 * It does not belong in coordination geometry — coordination geometry is how things are arranged in the molecule, or around a central atom. Unit cell volume should point to Lattice constant as it can be derived from the numbers in the box next to that eg a*b*c for an orthorhombic, or a^3 for cubic. I will write a section. Graeme Bartlett (talk) 13:39, 6 June 2015 (UTC)

Sandbox demo
re some questions:
 * Created Chembox/testcases11 for this. Talk stays here.
 * Parameter names UnitCellFormulas UnitCellVolume are most connvenient for editors (like you)?
 * LH link+text for Formulas todo.
 * There are three lattice constant data rows possible now. I will make them into one cell (mentioning 'Lattice constant' only once). Todo.
 * You can suggest other improvements. Any data-structure to be used/added (eg, same unit always, link to FCC crystal image like we do in see Aluminium? ).
 * Please take a checking look at the order of data rows. Can be better?
 * Postponed for now: reference and comment additions. Will add those later.
 * -DePiep (talk) 10:51, 9 June 2015 (UTC)
 * We could abbreviate this more to UnitCellZ for formulas, and UnitCellV for unit cell volume. Actually while checking up it seems that writers prefer molecules per cell about 1000× more often. This is despite many crystals not actually containing molecules, but rather an arrangements of ions, or atoms. So instead of UnitCellFormulas you could have UnitCellMolecules. For Unit Cell Volume I now have a section at Lattice constant. For α  β  γ the units are always °. For a b c the units are mostly Å, but some authors like nm (nanometers). Graeme Bartlett (talk) 11:38, 9 June 2015 (UTC)
 * re: about supporting the editor, not being perfect. I'd not use Z and V here. For less-familiar editors, that still is a mental step extra to remember or look up. UnitCellMolecules: can change. Is that the most known & specific word then? 'Molecules' is used everywhere, so could be less meaningful (less distinctive) here for that same half-familiar editor. -DePiep (talk) 11:51, 9 June 2015 (UTC)


 * Finalizing. See Chembox/testcases11. I've put the 3+3 lattice constants together in one data row (one cell). Remaining questions:
 * Do all lattice-changes look OK to you for the variants?
 * Are the new parameters named OK UnitCellFormulas UnitCellVolume for your fellow chemistry editors? (Just thinking, not like LattConst_Formulas LattConst_Volume then.)
 * Volume and Formulas are free text, shown unformatted. But the 6 constants themselves are structured & formatted in the infobox. So we need extra params like LattConst_ref and LattConst_comment then to position that info correctly. Where do I put those two? Once for all 6 constants at the end or two options, #1 after a-b-c and #2 after alpha-beta-gamma? -DePiep (talk) 09:20, 16 June 2015 (UTC)
 * I like UnitCell in the name more than LattConst, but that is just my opinion.
 * Free text is fine as for volume then we can have units of our choice, I use Å3 for volume. A LatticeConst_ref would be good, just insert it after the last of a b c or α β γ as the same reference should cover all of this. Graeme Bartlett (talk) 11:39, 16 June 2015 (UTC)
 * Done. _ref follows the 6 values directly, _Comment starts with a newline. (Note that _Comment can have its own ref added, being anytext). Pls take a good look, also for punctuation & variants. If you agree, I'll put this live (my secondary notes, below, can follow later). -DePiep (talk) 13:32, 16 June 2015 (UTC)
 * Done. _ref follows the 6 values directly, _Comment starts with a newline. (Note that _Comment can have its own ref added, being anytext). Pls take a good look, also for punctuation & variants. If you agree, I'll put this live (my secondary notes, below, can follow later). -DePiep (talk) 13:32, 16 June 2015 (UTC)


 * Processing deployment. New parameters:


 * -DePiep (talk) 09:40, 17 June 2015 (UTC)


 * ✅. ping . Secondary topics, section below, can follow later. -DePiep (talk) 10:04, 17 June 2015 (UTC)-DePiep (talk) 10:04, 17 June 2015 (UTC)

Secondary changes
Apart from the Volume and Formulas additions (see above), some more questions and suggestions arose.
 * Structure: change section title into "Crystal structure"? If all data rows are descriptions of the crystal, we can do this. (Dipole is?).
 * Also, is all data is crystal related, we can present the CrystStruc parameter as subheader (bold, over infobox width).
 * Pearson symbol: add extra data row? Could help Indium(III) sulfate. -DePiep (talk) 09:43, 16 June 2015 (UTC)
 * Structure could also be describing molecules, in which case shape, symmetry and coordination come into play. I will take a look at more possible values that might be useful. Dipole moment will normally describe one molecule. Graeme Bartlett (talk) 12:34, 17 June 2015 (UTC)
 * No urgency, I understand. Just let us know if you see improvements. One from me: we should nowrap each if the six lattice values. -19:37, 17 June 2015 (UTC)

IUPHAR ligand links update
Following this discussion:
 * 1) Many IUPHAR ligand values (ID's) have been systematically added by . 974 to Drugbox, 475 to Chembox. Now in total ~2000/16000 articles have this ligand, linked el.
 * 2) I will add the option to index IUPHAR_ligand parameters, each with a IUPHAR_ligand_Comment option. This is parallel with indexes like   and CASNoindex_Comment.
 * 3) IUPHAR_ligand_Other is added (once) by the same set pattern: allows any text after all indexed input (unlinked, unedited by {Chembox}).
 * 4) Existing IUPHAR_ligand keeps functioning & showing unchanged. It has added option IUPHAR_ligand_Comment just as well.
 * 5) See Chembox/testcases2. Full parameter set for the IUPHAR ligand data row:
 * IUPHAR_ligand=
 * IUPHAR_ligand_Comment=
 * IUPHAR_ligand1=
 * IUPHAR_ligand1_Comment=
 * IUPHAR_ligand2=
 * IUPHAR_ligand2_Comment=
 * IUPHAR_ligand3=
 * IUPHAR_ligand3_Comment=
 * IUPHAR_ligand4=
 * IUPHAR_ligand4_Comment=
 * IUPHAR_ligand5=
 * IUPHAR_ligand5_Comment=
 * IUPHAR_ligand_Other=
 * - preparing. -DePiep (talk) 09:22, 18 June 2015 (UTC)
 * ✅ -DePiep (talk) 09:53, 18 June 2015 (UTC)

EC Number link
Hello everyone,

I am new here as editor, but I often read and use Wikipedia articles for my studies.

I have noticed that the link to EC number in Chemical infobox point to ESIS web site which has been closed for more than 6 months.

For instance for Formaldehyde that gives EC number 200-001-8 which link as: http://esis.jrc.ec.europa.eu/lib/einecs_IS_reponse.php?genre=ECNO&entree=200-001-8

Why not to remove such link to any EC number or even better to update as direct link to another chemical information system like chemsub online with link as format http://chemsub.online.fr/ec_number/EC number.html like for formaldehyde: http://chemsub.online.fr/ec_number/200-001-8.html I found only this web site having a direct access to chemical data sheet via EC number.

Thank you.

--Chemistaddict (talk) 13:55, 6 June 2015 (UTC)
 * Welcome. This was discussed last weeks here. Proposed demos are here, do they look good? Within a few days, the new version will be put live. -DePiep (talk) 18:14, 6 June 2015 (UTC)
 * I must add: that discussion, and you too, conclude that there is no automatable link to a EC number site page. That is why that number is unlinked (in the demo). Can you explain why 'chemsub' would be a trustworthy alternative? Your example for 200-001-8: . -DePiep (talk) 22:45, 6 June 2015 (UTC)
 * The changes I pointed to are made. See #Template edits 7 June 2015. -DePiep (talk) 11:39, 8 June 2015 (UTC)
 * Thank you DePiep, sorry, I do not know really if I'm respecting rules of editing, I hope so. I do not know if chemsub is a trusted source, but it's so far the only one which provides direct link to any EC number (pointing to the right chemical substance). I'm more than 65 and dealing with EC numbers for ore than 30 years. I have been using ESIS since its start in 2002 if I remember well, it was the reference. But now, we count on you. Thank you.--Chemistaddict (talk) 14:30, 9 June 2015 (UTC)
 * First and foremost, you did not trespass anything. Instead you are welcome to mention any idea & concern as you did.
 * I'm not that familiar with the EC number (who could be?), but the essence is that we want to link to the publishing authority's site. That is called Authority control, and we prefer using template Authority control (originally about libraries that standardise names like for Princess Diana). These days this template will be expanded with chemical & medicine institutes that decide & publish id's.
 * And so, since ECHA does not have a site accessible (not even a definition for EC number I found, to link to), we can not link to that authority source. (A good example is the CAS RN, we can link automatically to (for ammonia).
 * To make things worse, I got the impression that not long ago the setup was changed (eg, EINECS was merged into EC number, a bit). And the earleir websites & links now are dead, as we know.
 * The site you propose to link to,, is only using that EC number, not defining it. If we use that link, this wikipedia would become a 'link farm' instead of providing information & sources. This is why the EC number is not linked.
 * Actually, since you are familiar with EC number, you could help the chemical infobox of course. As I said, we are in need of ECNA/EC number sources and maybe even an entrance to their database by EC number. The situation is even worse for "EC Index", of which we don't have any useful definition or link (this way, it will be removed from the infobox Chembox completely). In other words: what are the EC number people doing, actually? -DePiep (talk) 15:51, 9 June 2015 (UTC)
 * To DePiep: Concerning the merged you talked about, actually EINECS and EC number are the same. Official EC number includes EINECS, ELINCS and NLP (for a total of 106 199 chemical substances).
 * There is no proper definition of EC number, even was not the case in the ex ESIS. Consider just that a EC number is for Europe what is a CAS number for US.
 * Concerning EC index, it's as you know totally different issue.
 * And for the EC number people, which whom I had different exchanges and personally with the person who has developed ESIS, they "do not exist" as such, they might work in other activities.
 * It's all I can say so far concerning this subject. EC number was a good key for accessing chemicals, especially EU chemicals, anyway. --Chemistaddict (talk) 13:00, 22 June 2015 (UTC)
 * Yes this is how I understand it.
 * EC number now shows inputs EC number and EINECS in as being the same. But we can not link to a database page for a substance.
 * Of EC index we do not have a definition and no source that defines these numbers. So that datarow will be removed from completely.
 * If you see any strange things in this topic in articles, please note. -DePiep (talk) 14:13, 22 June 2015 (UTC)
 * The proposal to delete ECIndex is #here. -DePiep (talk) 20:36, 22 June 2015 (UTC)

Ordering Identifiers
I am ordering the Identifiers alphabetically. From random. -DePiep (talk) 19:27, 12 February 2015 (UTC)
 * Maybe the current order is according to importance, too. --Leyo 19:29, 12 February 2015 (UTC)
 * As you say: maybe. That is not enough. I am looking at it for a year now, and still have not discovered any structure (of course, if importance is in play then that should show). From alphabetic, we could split into a 2nd header "Specific identifiers" like medicine and countries (EU). The generic id's can remain in top. -DePiep (talk) 19:59, 12 February 2015 (UTC)
 * IMO CAS number and EC number should be first and second. --Leyo 20:41, 12 February 2015 (UTC)
 * And the others? How does one search? Not everybody knows the order of improtance. -DePiep (talk) 20:48, 12 February 2015 (UTC)
 * Most readers will be interested in the CAS number, but currently the very specific 3DMet and Beilstein Reference are first. What about waiting for other opinions? --Leyo 20:59, 12 February 2015 (UTC)
 * Better options can be made. As it was, it was chaos. Now, when CAS and 3 &times; EU are in top --somehow--, by what guide will the reader search for another one? Having to look twice up and down and still be insecure? Print it and use a pen? Plus: someone searching for CAS, why would that person not look for the letter "C"? As said, I'd like to learn how the other id's are presented. When I am looking for an id, I do not know how important it is in the list. -DePiep (talk) 21:11, 12 February 2015 (UTC)


 * These are some options to order the Identifiers (There are 23 optional datarows today):
 * 1. Keep by ABC as it is today (but we could apply list-changes eg 3, 4, 5 below).
 * 2. CAS in top always, with the CAS datarow having a double border line, the rest follows by ABC.
 * 3. Add a new section, the header saying "Special identifiers" or so. This section then has the medical and country-specific id's (ATC, RTECS, EU-defined, DrugBank). This splits up the longer list nicely & systematically. Both sections are by ABC, with/out idea #2 applied.
 * 4. Some rows have images not identifiers (eg Jmol 3D). These links (data rows) belong in the top "Images" section (show as a text row there). However, this can not be done before moving to Lua module (because, today one would have to copy-paste the SMILES id's to the top chembox-section, looking as if they are entered double in Chembox).
 * 5. Abbreviations go to the "Names" section (when in Lua module).
 * More ideas? -DePiep (talk) 08:19, 13 February 2015 (UTC)
 * I'd vote for option 2. I am interested in seeing opinions of other editors, too. --Leyo 20:21, 15 February 2015 (UTC)
 * It is not a "pick one out of five" list. Listen. I prepared and asked three questions, and then I spend time on five suggestions to think of. But all you keep replying is: "CAS must be in top". That is not a development. Now, what are your thoughts on the remarks made in this thread? -DePiep (talk) 21:45, 15 February 2015 (UTC)
 * Another thought: Certain identifiers are of interest to readers for reasons other than just being the ID in a database/part of an URL (e.g. CAS RN, EC no., ATC, SMILES). Opposite type identifiers include e.g. ChemSpider ID, KEGG, Beilstein, 3DMET. I would say that the former are more important to readers that the latter. --Leyo 23:28, 15 February 2015 (UTC)
 * Yes, so this is what I felt but could not point to. Shouldn't these be in a footnote set of links altogether? Or in a reference? I don't think these external links should be in the infobox at all. And we also removed the icon from showing. . -DePiep (talk) 10:18, 19 February 2015 (UTC)

Let's build a table just to get an overview. -DePiep (talk) 13:14, 19 February 2015 (UTC)

Table of id's

 * Table is under construction. Improvements may be added


 * Source = institute
 * id-type =true (CAS) or internal/non-original (3Dmet)
 * gen/spec: specific can be country, medicine
 * ext = external link (demo)
 * i'box: used in chembox, drugbox?

Revert
Can this ordering (diff) be reverted until consensus has been reached which order to use. --Dirk Beetstra T C 03:31, 4 May 2015 (UTC)
 * Pictogram voting question.svg Question: Where is the discussion on the order, what makes it controversial, and isn't that a little WP:BIKESHEDish? (I'll watch this page for a response, which is why I marked it as answered.) —  14:05, 4 May 2015 (UTC)
 * The discussion is above, but to put it in edits: suggestion by DePiep, first concern posted ('Maybe the order is on importance too' by Leyo), 2 minutes after suggestion, and implementation, 8 minutes after a concern was raised, first reply by DePiep 'As you say: maybe. That is not enough. . I am looking at it for a year now, and still have not discovered any structure (of course, if importance is in play then that should show).' Maybe there indeed was not a lot of structure, and that improvements would be needed, but DePiep just bolbly (well, not really, he first started a discussion but did not wait for answers even after trying to figure it out for a year himself) implemented the change without waiting for answers or suggestions on other possibilities.  I suggest that we revert to the status quo, and see whether other options should be explored, especially since concerns were raised only 2 minutes after suggesting, and the effect of the quick implementation on any further discussion.  --Dirk Beetstra T  C 03:37, 5 May 2015 (UTC)
 * Short: alphabetical order is better than random order. You all are invited, time ago, to propose improvements on that alphabetical order. No reason to revert. -DePiep (talk) 20:21, 8 May 2015 (UTC)
 * Short: Following a strict and unreflected alphabetical order of all parameters mentioned in the table above would not make any sense. Key parameters need to be on top. --Leyo 00:29, 9 May 2015 (UTC)
 * This is about the revert only. I think Beetastra intended to continue the discussion below. -DePiep (talk) 07:04, 9 May 2015 (UTC)
 * Short: That the implementation of the alphabetical order does not make sense is the whole reason for the revert. : "You all are invited, time ago, to propose improvements on that alphabetical order." - Can you point me that 'time ago' diff?  As far as I can see you suggested to implement alphabetical order and implemented it, without the consideration that maybe the old order did make sense (and, as a matter of fact, at least some of the identifiers were specifically chosen to be in a certain place, even if you did not know that).  Can you please Revert your Bold implementation of the alphabetical sorting of the fields, and allow for Discussion on what the order should be (which, I concur, may in the end be even alphabetical).  --Dirk Beetstra T  C 07:26, 10 May 2015 (UTC)
 * I wont go further in this (second) 'your talked wrong' approach. Technical13 saw it. -DePiep (talk) 08:07, 10 May 2015 (UTC)
 * I knew that was going to be your response. --Dirk Beetstra T  C 11:40, 10 May 2015 (UTC)

Ordering of identifiers and information

 * Per User:Leyo's points, I don't know if alphabetical order is the way forward and, per above, I do not think that that should be implemented without discussion. For the Identifiers, certainly the CAS number is the most important, and for some of the other databases the amount of useful data they provide gives them some importance (actually over CAS number which does not really convey information further).  On the other hand, identifiers like InChI's and SMILES are generated from the 'structures' of the compounds, and although true identifiers, not likely something that we would link out with.  IMHO, they should be grouped at the bottom, together with the external calculated structure generator.  For other parameters in other subboxes a similar reasoning should/could be made.  --Dirk Beetstra T  C 04:30, 7 May 2015 (UTC)
 * You can propose & discuss any further order improvements, as I started. Alphabetical order is better than random/chaotic order. -DePiep (talk) 20:23, 8 May 2015 (UTC)
 * The fact that today the order is alphabetically does not prohibit any change. The fact that I did open a discussion, and clearly spend time on it, can not be contructed into a negative argument.
 * As I tried to explain before, any sort criteria should be visible to the uninitiated reader. For example, of course we can just put CAS RN in top. However, then there is no visible structure for the list. The level of information may be a good grouping criteria, but that should be visualised. The reader can not see that from the data label (=LH column text). In other words, we can not make a hidden structure. We can think using extra lines or subheaders. -DePiep (talk) 21:25, 8 May 2015 (UTC)
 * The order was, to a certain extend, a chosen order (certain fields were in a certain place in the list because of a reason), it was not completely random, it was not completely chaotic. It is only you who says that alphabetical order is better than random/chaotic order.  You indeed did open a discussion, but failed to wait implementation, even while someone commented before you implemented.  Per Leyo above, I oppose the implementation of the alphabetical order.  --Dirk Beetstra T  C 07:30, 10 May 2015 (UTC)
 * What order do you propose? Can you add that to the table (eg adding a column with numbers or group description)? Then, how could we make that grouping visual? (subheaders, heavier row-bopttom lines, ...)? -DePiep (talk) 08:04, 10 May 2015 (UTC)
 * Partially, as it was - CASNo first, the more informative after that, InChI / SMILES last, they do not need to be grouped, the rest maybe in alphabetical order etc. etc. --Dirk Beetstra T  C 11:42, 10 May 2015 (UTC)
 * Whatever the ordering structure, it must be clear (say, visible) what that structure is. At least and for now, by alphabet has that advantage. If we apply a different ordering structure, we must convey that to the Reader somehow (otherwise, it would be a 'bag of data', as it is called in information. It appears chaotic/random for the Reader). A good example IMO is the current classification (grouping) of names in {Chembox}.
 * A first rough setup could be to move specified id's to the top, in groups. CAS being "Generic", SMILES being "generated from the 'structures' of the compounds", etc., and any remaining "Others" must be at the bottom (to keep the word 'Others' meaningful).
 * While we are at it, I think some entries are misplaced and do not belong in the Identifiers section. I guess abbr is more of a name. Jmol is an image only not an ID, but at the moment in the SectionN-setup we have it is difficult to reposition that to the top with other images, because it's defined (created in template code) from the SMILES input. There may be other candidates for repositioning, and all repositionings would require a maintenance job (move the parameter from SectionN=Chembox Identifiers to another SectionM=). Can be done, in the longer run. To be discussed per-ID, I suggest.
 * Another note: I think we should involve all {Drugbox} identifiers in this too (i.e., those not in {Chembox} today). Over there the same issue might play, and of course in the future a request might come along to add such an ID to {Chembox}.
 * Other subboxes (SectionsN) best be discussed separately I suggest, to prevent unnecessary complication. -DePiep (talk) 12:26, 10 May 2015 (UTC)
 * One could argue that for InChI and SMILES (well, we already collapsed them at the bottom until this disturbance which makes the display of them more chaotic), but the others should not be grouped. The identifiers that were in the top of the list were the more commonly used / more informative - most people simply look for the CAS first.  They do not have a special status and therefore no further grouping.  --Dirk Beetstra T  C 03:20, 11 May 2015 (UTC)
 * There are about 23. They do need an order, otherwise they appear chaotic. To you they may not do so, because you are that familiar with them, but the Reader needs support.
 * And I don't find "[they were the] more commonly used / more informative" convincing. Earlier you wrote "to a certain extend", "it was not completely random". So that only applies to some (which?) of the list. At least you could propose an order in the table for all of them. For a classification it must cover all, there is no "I don't mind" class.
 * About the collapsing: in mobile view, there is no collapsing option and a show/hide table is shown always. So we must design the infobox as if there is no collapsing. After that, collapsing is just a desktop extra. For this, there is no reason to put the foldables at the bottom, that does not clean up the mobile view. (The mobile view for a page can be tested by clicking on a link on the very last row of any article). -DePiep (talk) 10:56, 11 May 2015 (UTC)
 * I guess that nobody has any valid argument (i) for a strict alphabetical order and (ii) against CAS RN being the first identifier. --Leyo 20:40, 11 May 2015 (UTC)
 * - Wikipedia does not always follow mathematics, rules, etc. - we have free editorial choice. The order has been like this, seemingly random, for years, and NO-ONE has ever even asked a question why.  You barge in, and without waiting for remarks or answers you suggest ánd implement an ordering that had no consensus.  Now that is fine, but when opposition exists, then that edit should be reverted and the order should be discussed.  And if no consensus exists for a new order, then the status quo stays and a change is not implemented.  I've asked before, I'll ask again, can you please revert and get consensus for a new order.  --Dirk Beetstra T  C 03:28, 12 May 2015 (UTC)
 * Actually, looking more at it, the original order follows quite well an importance-ish order. CASNo (best known), pubchem (large, very well known), ChemSpiderID (large, of another big publishing house), drugbank (large, well known for drug information) are the 'bigger identifiers', 3DMet (now at the top) and Beilstein are more specialised information, and as I explained SMILES and InChI are at the bottom.  For the drugbox I expect that CASNo and drugbank are high up in the list of identifiers, pubchem probably, and then ChemSpiderID.  So your random order, DePiep, was actually not that random (actually, if the list was ordered by 'size of database', or 'age of organisation behind the database' (not counting SMILES and InChI, which are of a different type and therefore chosen to be at the bottom), you would likely get a seemingly very random list, still it is an order - and that order will not be far from what it was).  --Dirk Beetstra T  C 03:42, 12 May 2015 (UTC)
 * By the way, ABC is just an order, it is not necessarily organised. I still argue that the previous order was more organised than the current alphabetical order, and I disagree with the alphabetical order being organised.  --Dirk Beetstra T  C 05:43, 12 May 2015 (UTC)
 * re : that might be correct, but it is not an answer to the main quest here: by what system should we classify/order all the identifiers?. Please reread earlier notes I wrote on this, for example this and look at the Names-section as example. If things are unclear, please ask. About your reply here: your post leaves open all other questions but that CAS one. If you really want to say "I don't mind all the others", does that imply you leave it to others (like me) to choose anything sensible? -DePiep (talk) 09:58, 12 May 2015 (UTC)
 * re 1/2: You are still trying to construct my edits and even discussion openings as bad faith edits. Stop it. There will be no revert. As wiki works, you are invited to propose and discuss improvements. -DePiep (talk) 10:12, 12 May 2015 (UTC)
 * No, I do not construct them as bad faith, I construct them as Bold edits, but without consensus - Bold edits without consensus should be Reverted until consensus to perform them is formed (or, if no consensus to perform them is formed, the old status quo stands). The current situation is not an improvement, IMHO the old situation was way better.  I have hence proposed and discussed the improvements over the current version: reversion to the old situation.  --Dirk Beetstra T  C 11:01, 12 May 2015 (UTC)
 * Whatever. I planned reply 2/2 for content responses, but it puts some work on me to separate useful contributions from useless sidetracking in this thread. -DePiep (talk) 17:03, 12 May 2015 (UTC)
 * Not to charge the discussion, but to buy me extra time: I am puzzled by Beetstra's intention to revert to the old sequence with possibly some structure, argued that structure is not that needed (my words). -DePiep (talk) 21:07, 18 May 2015 (UTC)
 * - my statement is just that - that structure is not that needed anyway, but actually, there was more structure in it than you saw in the original version, and certain things were certainly placed in certain places for a reason. I am puzzled that you, when you did not see any structure, decided that alphabetical structure was the one to go for, and implemented that without considering that maybe there was a structure that you did not notice (nor did you bother to ask, nor did you bother to consult the community).  I keep insisting, the old version can be improved on, but is way better than the current one.  --Dirk Beetstra T  C 06:11, 19 May 2015 (UTC)
 * Bad news: absence of (visible) structure is not good for ~23 items. That's just not how we should present info in this encyclopedia.
 * Good news: structuring criteria you did mention are great. Of course CAS NR can be in top, by being category "seneral" or "universal". In development, we could have a single second category "Others" with the other 22.
 * later more. -DePiep (talk) 22:11, 21 May 2015 (UTC)
 * , a working proposal. I can put a table below here, with those ~23 Identifiers and their properties (like groups, ..), old & ABC order, etc. Then shall we both improve that into a better ordering, here? -DePiep (talk) 22:25, 21 May 2015 (UTC)
 * "absence of (visible) structure is not good for ~23 items." .. first of all, who says that there is no (visible) structure, and second, who says that absence of (visible) structure is not good (per the argument I made above: "The order has been like this, seemingly random, for years, " You barge in, and without waiting for remarks or answers you suggest ánd implement an ordering that had no consensus."). To me, the structure/order was quite clear, and seen the lack of questions and/or remarks about this, it bothered no-one.  Here you implement the alphabetical order, and immediately you have two people arguing that that is not optimal.  See the difference?  Again, there was structure, the order was not random, and even if it was, there is no Wikipedia rule to state that that is a problem, and in any case, it did not bother anyone.  And the order now is way more random than what it was.
 * I have a quite optimal order: the one that was in there before you alphabetized it. The more used above, InChI/SMILES-like ones at the bottom, and the rest in the middle.  You can put that table with the old order here, and we may chose to swap one of them, but that is about it - they were reasonably ordered 'by importance', seemingly random but actually not.  --Dirk Beetstra T  C 03:36, 24 May 2015 (UTC)
 * In general, I see again your statements that the old order was better without substantiation. You also repeat that the timing of me opening the talk here frustrated discussion, but that does not hold because you have not come forward with any arguments and cooperation WRT the change since (instead, you did find time & energy to stab a PA elsewhere). In other words, if I'd left the change in the sandbox since Feb 12 for fourteen weeks until today, you'd still not have made a useful contribution. (For example: "To me, the structure/order was quite clear, ..." may be true, but why didn't you elaborate and start explaining? "To me ... it is" is not an argument). I also not that your shouted "no one" is incorrect, because quite clearly I did note the issue, and Leyo has written approvements for parts; I might also find contradictions or unclearities in your contributions. Given that you put so much effort in the opening paragraphs, I'd invite you to set up that overview table you finally mention. -DePiep (talk) 12:11, 26 May 2015 (UTC)

CAS RN in top
Having reread this whole topic & thread: I conclude that best and undisputed is to put CAS RN in top of the identifiers, nothing objects. It follows 's first comments,. This can be done without extra visual effects (I otherwise would require). It is good for our Readers, looks intuitive, and no harm in sight.

Below CAS RN all other ~20 ID's alphabetically, undiscriminated. So the order is:. Absent any categorizing criteria (I am still looking for), we have no subgrouping. Also, any further grouping requires some visual clue (like a subheader: "Special ID's:"). All this can be added later, once we agree on categorizing/grouping/presentation. None of this prejudices putting CAS RN in top. -DePiep (talk) 21:29, 22 June 2015 (UTC)
 * ✅ -DePiep (talk) 22:00, 22 June 2015 (UTC)

Broken supplemental ATC codes, redundant entries
Both and  support ATC codes and DrugBank identifiers. I think it is redundant to include these identifiers in both locations. I propose they be removed from, leaving the identifiers only in.

Additionally, the supplemental ATC codes (ATC_Supplemental) do not work for either or. See Nicotine for an example of how they are presently working in the. See Ethanol (data page) for an example of how they are presently not working for the Chembox. The values are present in the infobox for the data page but the supplemental values do not appear. Sizeofint (talk) 02:49, 16 April 2015 (UTC)
 * Yes, yes. Later more. -DePiep (talk) 06:56, 16 April 2015 (UTC)
 * Question: is ATC code an identifier? Shouldn't it be in Pharmacology, as just a (medical) property? -DePiep (talk) 16:59, 16 April 2015 (UTC)
 * Same for DrugBank: why not under "Pharma"?
 * ATC_Supplemental now shows (se Nicotine). -DePiep (talk) 17:50, 16 April 2015 (UTC)
 * Thanks! ATC code suggests that it is a classification rather than an identifier as I had assumed. You are probably right about keeping it under Pharmacology. Sizeofint (talk) 18:40, 16 April 2015 (UTC)
 * Yes, classification is the right word for ATC. Now DrugBank is an identifier, but at least in I'd expect it with medicine/pharma still. That's a more specific place. -DePiep (talk) 18:55, 16 April 2015 (UTC)
 * I'd be in favor of that. I'm more interested in eliminating the redundancy than which template it ends up in. Sizeofint (talk) 23:48, 16 April 2015 (UTC)
 * ✅. See section below. -DePiep (talk) 11:46, 18 April 2015 (UTC)

ATC and DrugBank deprecations
ATC parameters: deprecated in. Should be in

DrugBank parameters: deprecated in. Should be in

Offending articles are listed in:.

Also, all articles with depecated parameters are listed in

Maintenance task: any input should be moved from a  to. Example: [//en.wikipedia.org/w/index.php?title=Ethylenediaminetetraacetic_acid&diff=657026853&oldid=656557877] for this article. The maximum number of articles is about 450 for ATC.. and 450 for DrugBank..; previous numbers in the categories (i.e. before these were added): 475 articles in "misplaced & deprecated", 522 in "unknown parameter". Note that multiple categorisation reasons (say, "A" and "T") result in a single category listing, under an arbitrary letter).

When this cleanup is done, the parameters will be removed from code (will not show in that section any more). -DePiep (talk) 11:46, 18 April 2015 (UTC)


 * I partially disagree with this - drugbank number uniquely identifies a certain compound (generally a compound/mixture with a pharmacological activity), and should hence be in the identifiers section. I am not too familiar with the ATC-codes, but I do indeed not think that a certain ATC-code is uniquely identifying a compound, it is more of a classification.
 * Please do not move the drugbank parameter to the pharmacology section, the pharmacology section should be for things like activities, LD50s (though that could also be a hazard-parameter) etc. --Dirk Beetstra T  C 07:08, 19 April 2015 (UTC)
 * For now, it is only 'deprecated' in documentation/intention: it still shows when editcode-entered in section Identifiers (said shortly).
 * For argument: I disagree with Beetstra. Yes DrugBank is an identifier (dozens are), but it is very specific to pharmacology. Chemical--human interaction. So we should put it there. More specific = better. -DePiep (talk) 19:53, 19 April 2015 (UTC)
 * Im with Beetstra - identifiers in the top (and collapsed but not CAS). And IMHO I think ATC should not be in the infobox at all. I do not thin its helpful to the reader of chemicals. We have for some years ago removed a lot of entrys because the infobox was pretty big, but would like to have NMR data back again. Christian75 (talk) 20:17, 19 April 2015 (UTC)
 * Sigh. Those commentors only showing up afterwards, and never ever putting forward an improvement. Never, ever. -DePiep (talk) 20:30, 19 April 2015 (UTC)
 * No its 3-4 four days since your made the suggestion. You should wait at least a week for big changes. Many people doesnt read Wikipedia daily. Christian75 (talk) 21:12, 19 April 2015 (UTC)
 * As I said: no improvement ever. -DePiep (talk) 22:54, 19 April 2015 (UTC)
 * It is because of you and your attiTude,, that I choose not to spend extra time on big templates like and . Because: whatever I do, editors like you always come back afterwards to throw shit. -DePiep (talk) 23:23, 19 April 2015 (UTC)
 * No, when I (we) come afterwards its wrong, when we come when you are "programming" we should wait because we are interfering with your work?[//en.wikipedia.org/w/index.php?title=Wikipedia_talk:Chemical_infobox&diff=653672922&oldid=653661610][//en.wikipedia.org/w/index.php?title=Wikipedia_talk:Chemical_infobox&diff=654211764&oldid=654209928]. And if its before, the answer is later. I only "complains" about the big things. But I really think that this infobox is crazy. You never know when to use camel case or _ (or both), and all the _ref could be done a lot more smoothly, and some times the words are spelled out, sometimes not. E.g. melting (which it has been for years) was changed to MeltingPt - the reference is called MeltingPt_ref (no big R in ref, and a _ to separate the two words, despite melting point are two words too, and point is normally written pt (with small p)... Just some comments to show that I have a lot of opinions about the changes to the box, but normally doesn't write anything about it - just watching. Christian75 (talk) 10:59, 20 April 2015 (UTC)

And as I said, drugbank is an identifier, it is not pharmacological data. Identifiers with identifiers, pharmacological data in the pharmacology section. There are a LOT of chemicals that are identified in the drugbank where the majority of the data and content of the article is purely chemical, and for which the pharmacological data is just a minor part of the article. Please put it back in the identifier section, where it belongs, and I will read up on ATC code. --Dirk Beetstra T C 04:24, 20 April 2015 (UTC)
 * I disagree with Beetstra, with reasons already mentioned above and more (eg, data-independency). But alas since Beetstra seems to be Director of Knowledge on Wikipedia, I can not win any argument. -DePiep (talk) 19:17, 22 April 2015 (UTC)
 * Clearly, as with the 'lethal dose' vs. 'median lethal dose' situation, your argument is that you should have full freedom to implement the changes in whichever way you want them, and we should not even counter your arguments, nay, we should not even interfere with that - we should just be grateful that you inform us beforehand. I actually even wonder why you are here asking these things, after all you know that implementing 'lethal dose' was the right choice, as that you here simply have decided that drugbank, even though it is an identifier, should be in the pharmacology section as that is where people who want to know about drugs would want to find that identifier.  --Dirk Beetstra T  C 07:37, 24 April 2015 (UTC)
 * Why talk with Beetstra when he edits their way anyway? The point is, Mr know-it-all&do-it-all, that you edited without discussion, and now you come back here to join an early discussion to discuss your edit afterwards. That is not wiki. That is leapfrogging. Or let me spell it out: editing without joining the discussion is editwarring. -DePiep (talk)
 * I don't know, you suggested this on 18, I was here on 19 objecting to a part of the change, I have not touched this part, just commented on a part that you discussed before implementing. This section is about a.o. the drugbank identifier, and you obviously do not have consensus to move that into the pharmacology section.  The rest of the reply will be in the appropriate section, I suggest that you keep your comments there as well.  --Dirk Beetstra T  C 03:56, 29 April 2015 (UTC)
 * Concur with Dirk, and note that M. DePiep has a long history of resistance to consensus when it disagrees with his opinions, and a parallel history of personal disrespect in such discussions. If this gets elevated to a noticeboard for discussion, ping me, please. Le Prof  Leprof 7272 (talk) 03:19, 1 May 2015 (UTC)
 * , this is concerting in bad faith. You could withdraw this. -DePiep (talk) 22:21, 3 May 2015 (UTC)

ATC and DrugBank deprecations reversion
As this implementation ([//en.wikipedia.org/w/index.php?title=Template:Chembox_Pharmacology&diff=prev&oldid=657023835 diff], [//en.wikipedia.org/w/index.php?title=Template:Chembox_Identifiers&diff=prev&oldid=657023830 diff], as well as documentation, and some implementations on pages) clearly did not receive consensus, can this please be reverted back to the earlier state, and then properly discussed. Thanks. --Dirk Beetstra T C 11:21, 3 May 2015 (UTC)
 * Yes check.svg Done Please update the documentation yourself as is appropriate. —  14:11, 4 May 2015 (UTC)
 * Denied. Can someone stop talk-deaf Beetstra, please? -DePiep (talk) 03:02, 5 May 2015 (UTC)
 * ✅ again., you seem to be edit warring on a TE protected template against consensus. Please discuss before rereverting again. Thanks. —  03:09, 5 May 2015 (UTC)
 * No, AFAIK my account is not compromised. Btw, are you sane yourself? Beetstra --a friend of you then-- is behaving weird. Beetsra is in an "revert-dont-talk" mode. That's bad! Can you talk to him, help him? -DePiep (talk) 03:23, 5 May 2015 (UTC)
 * You say that edit warring is strange for DePiep, see another discussion above (the point what DePiep is alluding to in his above reply), and history of Template:Chembox LD50 and history of Template:Chembox LC50, as well as the way of implementing the ordering of identifiers (see Wikipedia_talk:Chemical_infobox). --Dirk Beetstra T  C 03:42, 5 May 2015 (UTC)
 * Who put that edit template-protected} here? -DePiep (talk) 04:05, 5 May 2015 (UTC)
 * I did, you could have seen that from the history. I hope you understand why I took that approach.  --Dirk Beetstra T  C 04:49, 5 May 2015 (UTC)


 * I am sane enough, never suggested either of you were not. You should know by now, as an introvert, I have no friends; so no, Dirk isn't my friend. Based on my previous interactions with DePiep, this kind of edit warring is fairly unusual. The template is fully protected for now, and I'm going to bed. Since I don't really care what arguments are or aren't in this template, I'll happily work with everyone that has commented on this and try to help determine the consensus and request an admin make ay changes that consensus supports. In the meantime, I'd suggest you both take a break from this topic and WP:CALM yourselves down remembering this is only Wikipedia and not a matter of life or death. Good night! —
 * Tech13 and Beetstra will go free -- admins. -DePiep (talk) 04:18, 5 May 2015 (UTC)
 * - If you go through the threads, I think you will notice more editors are involved in this situation.  Anyways, I am looking forward to arguments from DePiep supporting the changes they suggested.  --Dirk Beetstra T  C 04:49, 5 May 2015 (UTC)
 * I did notice there were multiple editors in this discussion, and DePiep was going right at wheel warring to push their preferred version through. I decided after the third revision to request full protection (so neither him nor I can change the template directly at this point) to prevent this from getting to a point where DePiep was liable to loose his privileges and be blocked for 3RR (although he may still loose TE).  Anyways, I'm going to kind of sit back a little and watch while discussion unfolds (too busy with finals this week to really interject much). —   20:13, 5 May 2015 (UTC)
 * lol: Prof 7272 is a troll, of course. That's your friend, Beetstra. -DePiep (talk) 04:56, 5 May 2015 (UTC)
 * I'd consider that a PA DePiep unless you can back up that claim with evidence, I need to ask you to retract that comment. Let's please keep this civil and discuss what changes need to be made here and why and figure out how to get it done. Thanks. —  20:13, 5 May 2015 (UTC)

- revert this edit, which was not discussed, and which does not contain any relevant edit summary. Christian75 (talk) 05:36, 5 May 2015 (UTC)
 * - that was a self-revert by to the version implemented by  above after my edit request.  --Dirk Beetstra T  C 05:43, 5 May 2015 (UTC)
 * Oops my mistake. Christian75 (talk) 06:30, 5 May 2015 (UTC)
 * This is edit warring, really. -DePiep (talk) 05:48, 5 May 2015 (UTC)


 * Beetstra@undefined. Status update please. /doc's are wrong for sure. Anything about the main subtemplates involved? Structured thoughts anyone? -DePiep (talk) 22:38, 22 June 2015 (UTC)

ATC and DrugBank deprecations new discussion
So after these shenanigans the original question still stands. We currently have redundant entries for ATC code and the DrugBank identifier in the "Identifier" and "Pharmacology" sections. Should this redundancy be eliminated and if so which sections should these entries be placed in? Sizeofint (talk) 00:06, 6 May 2015 (UTC)
 * As per above comments, 'drugbank' is an identifier, and should be in the identifiers-section, and if I understand correctly, ATC-codes are more classifications, it tells you something about a drug. If that is so, it indeed is not an identifier, and this one should be in another section - I guess the Pharmacology section is more appropriate.  --Dirk Beetstra T  C 03:16, 6 May 2015 (UTC)

Change MSDS to SDS
The United Nations Globally Harmonized System of Classification and Labelling of Chemicals (GHS) calls for the harmonization of data sheets for chemicals, using the name "Safety Data Sheet" (SDS). It's not a law or regulation, but a guideline that countries should adopt. All large, English-speaking countries have adopted the guidelines—the EU (UK & Ireland), US, Canada, Australia, & New Zealand—and the sheets formerly known as Material Safety Data Sheets (MSDS) will now be called SDSs in these jurisdictions (see also Talk:Safety data sheet). I have moved the Wikipedia article on this subject from material safety data sheet to safety data sheet, given the UN guidelines and use in all large, English-speaking countries.

Template:Chembox, Template:Chembox Hazards, and any other relevant infoboxes need to be adjusted to use the term SDS, replacing MSDS (this appears in the "Hazards" section of the Chembox template). I plan to make a request at Bot requests to change other occurrences in articles (eg. on data pages such as Methanol (data page)), so please note anything that could be included in the request (such as changing all occurrences of "ExternalMSDS" parameter to "ExternalSDS", if that is appropriate). AHeneen (talk) 08:06, 28 May 2015 (UTC)
 * If the article is moved, then I would suggest that all templates calling that should just be changed to reflect that. --Dirk Beetstra T  C 08:15, 28 May 2015 (UTC)
 * Implemented, moved the templates, renamed the calling. Please check if something is missing.  --Dirk Beetstra T  C 08:21, 28 May 2015 (UTC)
 * The template documentation needs to be updated. AHeneen (talk) 08:37, 28 May 2015 (UTC)
 * We need to be clear on the spelling of data page subsection: or, because it now differs while we use automated linking. This is urgent because of the BOT request. My only preference is consistency. -DePiep (talk) 12:15, 30 May 2015 (UTC)
 * The article is currently called 'Safety data sheet', so I guess no camel case throughout, then. --Dirk Beetstra T  C 03:38, 31 May 2015 (UTC)

SDS handling
"When the  exists, link to , and do not show any ExternalSDS input." Example: for Ammonia, the datapage exists so the link shown is to Ammonia_(data_page), labeled "External SDS". And existing input ExternalSDS is not shown or used. The question is: do we want this?
 * A question not about this change, but about SDS and how we show it in the infobox. The template code now says/does:

I also note that when the datapage exists, an extra section is added to the infobox: "Supplementary data page", so that page is linked more often from the infobox. There are ~150 such datapages, see.

Minor notes: 1. The wikilabel "External SDS" does not sound correct, it is a wiki page. 2. The targeted #section name is changed here to SDS, but not in the actual data page. -DePiep (talk) 15:05, 28 May 2015 (UTC)


 * Note that I have made a request for a bot to change the chemical data pages, changing the section titles from "Material safety data sheet" to "Safety data sheet" (Bot requests). Someone familiar with the chemical infoboxes needs to coordinate with those who respond to the bot request what (if any) changes should be made to the infobox text in chemical articles...for example, should the "ExternalMSDS" parameter be changed to "ExternalSDS"? If yes, then a bot can edit all the articles to change the parameter name. I am not familiar with template coding (except navboxes), so this is something that an editor familiar with these infoboxes needs to coordinate. AHeneen (talk) 01:40, 29 May 2015 (UTC)
 * ExternalMSDS is deprecated but not eliminated. It will not be documented. ExternalSDS is the new parameter. There is no requirement to edit that name in the articles.
 * Do you have an opinion on my main point: when datapage exists, any input ExternalSDS is not shown. eg Ammonia. Do we want that? -DePiep (talk) 10:37, 29 May 2015 (UTC)

I am not in favor of the “External(M)SDS” parameter anyway. IMO any non-self-evident value should be referenced using ref tags. There are cases, where some values are included in an external SDS, while others are found in a different SDS. Hence, it does not make sense to link to one SDS only. --Leyo 12:26, 29 May 2015 (UTC)
 * Could that be written into a proposal, for the SDS's? -DePiep (talk) 13:11, 29 May 2015 (UTC)
 * I don't understand, sorry. --Leyo 22:39, 29 May 2015 (UTC)
 * Can you start a proposal on how we should handle & show SDS's? We have:
 * as infobox section,  as internal link - labeled External SDS confusingly, and ExternalSDS parameter (likely having external links; weirdly not showing when (data page) exists.).
 * Or else: how would you set SDS up from scratch, for this infobox? -DePiep (talk) 22:48, 29 May 2015 (UTC)
 * IMO any non-self-evident value needs to have a  behind. --Leyo 11:33, 30 May 2015 (UTC)
 * Very well. But SDS is not a value, it's a page (data sheet); that's internal and/or external links. How should it look like in the infobox? For ammonia:
 * SDS | ICSC 0414 (anhydrous)
 * SDS | SDS (data page)
 * I see no use to add a &lt;ref> to such a link (internal or external). -DePiep (talk) 12:07, 30 May 2015 (UTC)
 * I was referring to parameters such as melting point, density or solubility that should have  after the value. --Leyo 19:36, 30 May 2015 (UTC)
 * SDS does not need to be referenced, data pulled out of a specific SDS would need to be referenced to the specific SDS it comes from. --Dirk Beetstra T  C 03:38, 31 May 2015 (UTC)
 * Yes, that is what I meant. --Leyo 09:47, 31 May 2015 (UTC)

A quick repair
Current presentation of SDS has two flaws (demo's from ammonia). I propose to correct them. 1. The internal link to the a data page is wikilabeled (shows text):
 * SDS | External SDS ❌

This is incorrect text, it is not external. I propose to make that
 * SDS | Data page

2. When a data page exists that one is linked to OK, but then any regular input for ExternalSDS/ExternalMSDS is not used & not shown at all. I don't see why that is. I propose to have that input value shown:
 * SDS | ICSC 0414 (anhydrous)

See demo at Testcases. To check datapage-detection: use ammonia with. Other improvements in discussion (see section above, eg by Leyo) can be added later on without prejuduce. Comments? -DePiep (talk) 12:48, 30 May 2015 (UTC)
 * Todo/willdo: no repetition of SDS in LH label. -DePiep (talk) 13:05, 30 May 2015 (UTC)
 * Maybe the LH label should now be written out (I agree that the word 'external' should go)
 * Safety data sheet | Data page
 * The abbrev. is not actually needed there, there is enough space, and readers don't have to go the extra step to see what SDS actually stands for. --Dirk Beetstra T  C 03:38, 31 May 2015 (UTC)
 * All right. And when both, it looks ~like:
 * Safety data sheet | Data page
 * | ICSC 0414 (anhydrous)
 * -DePiep (talk) 23:52, 2 June 2015 (UTC)
 * Done, both will show. See the Testcases. Also added: parameter Hazards_data_page to set (and overwrite) an exsting data page. So: Main page will overwrite Ammonia (data page). -DePiep (talk) 12:10, 5 June 2015 (UTC)
 * ✅. See #Template edits 7 June 2015. -DePiep (talk) 11:40, 8 June 2015 (UTC)

Current status
As of 23:18, 22 June 2015 (UTC)
 * An existing PAGENAME (data page)) automatically appears in SectionN= (see Ammonia)
 * An existing PAGENAME (data page)) automatically appears as "Supplementary data page". (again; see Ammonia)
 * In Section one can add ExternalSDS.
 * Optionally, in data page overwrites an existing data page name.
 * -DePiep (talk) 23:18, 22 June 2015 (UTC)

Add onset and duration of action to pharmacology section
{Drugbox} has onset and duration_of_action. I think these could be useful in the pharmacology subsection of {Chembox}}. Can these be added? Sizeofint (talk) 20:14, 18 June 2015 (UTC)
 * See the testcases (drugbox added to compare). Questions:
 * What is the right order for the rows?
 * What & where with those 'routes of admin'?
 * Are the lefthand texts OK? (read)
 * Are the lefthand targets OK? (click)
 * Since this all must make sense, they willl be be made the same in . Exception: metabolism vs drug metabolism. -DePiep (talk) 21:10, 18 June 2015 (UTC)
 * Perhaps this order?


 * AdminRoutes =
 * Bioavail =
 * ProteinBound =
 * Metabolism =
 * Metabolites =
 * OnsetOfAction =
 * HalfLife =
 * DurationOfAction=
 * Excretion =
 * The lefthand texts and targets look mostly fine. I note that "Elimination half life" redirects to "Biological half life". The target should be changed to "Biological half life". I don't have an opinion as to if the text should be changed as well. Sizeofint (talk) 22:18, 18 June 2015 (UTC)
 * Fine. Done in testpage. -DePiep (talk) 23:19, 18 June 2015 (UTC)
 * Biological half-life to be the lefthand text, after reading the article. Word 'elimination' does not even appear, and 'biological' is clear to me (but that could be because I work on isotopes too...). -DePiep (talk) 07:49, 19 June 2015 (UTC)
 * Added a subheader, linking to pharmacokinetics. Same in.
 * Ready for deployment. See the testcases. -DePiep (talk) 09:20, 22 June 2015 (UTC)
 * ✅. Parameters added. -DePiep (talk) 11:35, 23 June 2015 (UTC)

Upcoming presentation changes
Following data additions requested (pharmacokinetics here and LCLo here), I've prepared some useful/needed presentation changes (layout, order, format, whitespace).
 * Introducing subheader for a set (group) of data rows. This allows to present as a group e.g. the data LD50, LC50, LDLo, LCLo under a single subheader titletext. It uses indenting and a subtle shift of bg color (grey a bit darker).
 * Applied to pharmacokinetics, lethal amount, NIOSH data (demo/testcases for pharma, hazards).


 * Re-add the border to the yellowish headers. This moves away from the more white-ish (bleaker) Infobox style, but is needed to have consistency over various situations (no images, separate header from subheader, ...) in . See the hazards demo.

I plan to deploy this shortly. Any remarks? -DePiep (talk) 09:18, 22 June 2015 (UTC)
 * Looks good! Thanks Depiep! Sizeofint (talk) 15:04, 22 June 2015 (UTC)
 * ✅. -DePiep (talk) 11:35, 23 June 2015 (UTC)

Adding LCLo and LDLo
Hello all, I was wondering what people thought of adding LCLo and LDLo values to the chembox. I think it could be a useful addition, especially in situations where there isn't literature with an LC/LD50 and there is just a LD/LCLo. Best, Emily Temple-Wood (NIOSH) (talk) 01:40, 29 May 2015 (UTC)
 * I see no issue with this, I'm given to believe that LD50 isn't really a useful value anyway (when would you even want to kill half of a group of things?). Lowest published lethal dose does seem much more relevant. However, if this goes ahead can I request that some work be done on Lethal dose. Lowest published lethal dose should probably be merged into it, and redirects created for LCLo etc. likewise our articles on PEL and REL could do with some modernizing. Emily is doing an excellent job of adding huge amounts of data, so we should make sure that terms used are easy to find and well explained and references. --Project Osprey (talk) 08:29, 29 May 2015 (UTC)
 * What would be the exact lefthand text for these? And how do should they relate to existing LD50 and LC50 data rows (sequence, in one row, ...)? -DePiep (talk) 10:00, 29 May 2015 (UTC)
 * I propose either:
 * {| class="wikitable"

! colspan=2 style="background:#F8EABA" | Hazards
 * style="width:12em" | LCLo (Lowest lethal dose)
 * e.g. 50 ppm, 50 mg/kg
 * }
 * }


 * or


 * {| class="wikitable"

! colspan=2 style="background:#F8EABA" | Hazards
 * style="width:12em" | LCLo
 * e.g. 50 ppm, 50 mg/kg
 * }
 * Units should not be automatically added (the value might have one of several possible units (ppm, or mg/kg etc), so the freedom to add such units would be needed). I would suggest adding it on own row, just below LD50 in chembox. --Project Osprey (talk) 10:38, 29 May 2015 (UTC)
 * I'd prefer the top one. Can use subscript: LDLo. There are two new data to position, LDLo below LD50 and LCLo below LC50 I guess? -DePiep (talk) 10:48, 29 May 2015 (UTC)
 * I agree, but lets wait and see what thinks, it's her idea after all. --Project Osprey (talk) 11:14, 29 May 2015 (UTC)
 * I'm thinking of this: both LC-values together in one box:
 * {| class="wikitable"
 * {| class="wikitable"

! colspan=2 style="background:#F8EABA" | Hazards
 * style="width:12em" | LC50 (Lowest published lethal dose) LCLo (Lowest lethal dose)
 * 11,900 mg/kg 50 ppm, 50 mg/kg
 * }
 * -DePiep (talk) 19:09, 29 May 2015 (UTC)
 * Text in LH label are getting long. They shoudld be hinting, not defining. Also, LCLo has no target page.
 * All together, this is getting very detailed. I expect more LD... types of data. Would it help if we add a general-purpose data row: LD_label for free LH label text, and LD for its data?
 * Anyway, here is a first sandbox demo. See also Testcases10. Params for now are LDLo, LCLo. -DePiep (talk) 19:58, 29 May 2015 (UTC)
 * Anyway, here is a first sandbox demo. See also Testcases10. Params for now are LDLo, LCLo. -DePiep (talk) 19:58, 29 May 2015 (UTC)


 * Sorry it took me so long to get back to you - this looks great and I'm so glad you're both on board with this idea! Thank you both so much. :) Emily Temple-Wood (NIOSH) (talk) 01:54, 30 May 2015 (UTC)
 * Please read the points I noted in my last post. It is getting very detailed & long. -DePiep (talk) 10:06, 30 May 2015 (UTC)
 * I don't think there are any more LD types of data, so I'm not sure a general-purpose data row would be helpful particularly. Emily Temple-Wood (NIOSH) (talk) 20:26, 30 May 2015 (UTC)
 * Emily and others, I disapprove of this LD/LC-set of four, as it is now. Texts are too long, the topic area is fuzzy (see ), the lefthand (LH) labels take toooo much space, into three lines even (they should just describe or hint, not define the indicator!), and LCLo does not even have a wikilemma. (Why would we note a value that does not even have a wiki link?). -DePiep (talk) 23:21, 30 May 2015 (UTC)

We could pipe the links, which would solve the problem of them being so wordy. LCLo should absolutely have an article and I will put it on my to-do-asap list. (perhaps it will even be done by the time you see this message! :D) Emily Temple-Wood (NIOSH) (talk) 02:16, 31 May 2015 (UTC)
 * New: Lethal concentration low. -DePiep (talk) 13:54, 5 June 2015 (UTC)
 * - You could do without the written out fieldname (just call it LD50, LDLo, LC50 and LCLo respectively), though I prefer the written out name since it is more clear to the reader ('Median lethal dose' is more informative and gives the reader an idea what is being talked about). --Dirk Beetstra T  C 03:50, 31 May 2015 (UTC)
 * I would favour the use of Template:Abbrlink (e.g. LDLo). --Project Osprey (talk) 17:48, 31 May 2015 (UTC)
 * I didn't even know that existed - that seems like a good solution! Emily Temple-Wood (NIOSH) (talk) 16:40, 1 June 2015 (UTC)
 * - I think that is a great solution! --Dirk Beetstra T  C 06:10, 2 June 2015 (UTC)
 * re Leyo: 1. It's not an abbreviation, it's a quantity (a qualified one). 2. Though w3c introduced it for abbreviations, it is not intended for other tooltipping usage. 3. In mobile view, it appears as a regular link. No abbr-effect available. 4. WP:ACCESS: we should not require a secondary action (like click or hover) to show information.
 * re short LD50 only: In general, the texts "LD50" etc. are not commonly known, so we should add information.
 * But I don't think it should be a full definition, a descriptive addition is OK. So I propose pattern like:
 * Lethal dose LD
 * Actual linking (=the wikilabel) might change. -DePiep (talk) 11:19, 2 June 2015 (UTC)
 * I agree with the first part, I'd prefer the terms to have a visible explanation. But per the comparison of LD50 and LDLo - The term 'Lethal dose' is not enough and confusing, it has to include 'median' and 'Lowest' at the least to distinguish between the two.  --Dirk Beetstra T  C 11:52, 2 June 2015 (UTC)
 * Yes it's very very subtle. Compare Readers' view:
 * Lethal dose LD50
 * Lethal dose LDLo
 * Of course, the target links will differ. I like most of it though, good links added. -DePiep (talk) 23:58, 2 June 2015 (UTC)
 * The point was not to rely on the target links. I think that the difference is too subtle - a reader will read the text, not interprete the subscript on the identifier.  --Dirk Beetstra T  C 11:26, 3 June 2015 (UTC)

(arbitrary break, introducing sublevels)

 * The only work-around I can think of would be to break the data into sub-tables. Is this possible and convenient? --Project Osprey (talk) 12:48, 2 June 2015 (UTC)
 * Demo 2 - Project Osprey


 * A good and fresh approach I see! A clear and convincing view! Unfortunately, in {Chembox} this is to be in the "Hazards" infobox section, so "Lethal dose" can not be at that level. The colored section header is not a sub to Hazards, this way. A 3-leveled {Chembox} is a good topic too, but hard to talk in here. Note, I ask, how good the short wording reads & looks for us and for our Reader. (I add: good to drop the wikilinking for now). -DePiep (talk) 22:12, 2 June 2015 (UTC)
 * This is an approach worth discussing - it could be used elsewhere as well. As long as the second-level template is handling it completely (it should not require another 'sub-box' definition in the sub-box).  We do have to adapt these sub-headers so they are distinguised from the 'Hazards'-sub-box-level header, otherwise we might get situations like:


 * One could consider:


 * (i.e. drop the bolding of the sublevel, giving it a somewhat different (lighter?) colour). Still, how to make clear that the three 'belong' together, and that the fourth one is something else.  Making the separator lines different (e.g. dotted or dashed between these three), or forcing the fields that need a sub-header to be at the bottom (so that there are no unrelated fields without an own subheader below them)?  --Dirk Beetstra T  C 11:26, 3 June 2015 (UTC)
 * Yes, good to add the concept of "subsection" to . Later more. -DePiep (talk) 23:35, 3 June 2015 (UTC)
 * ...Second thoughts. In general, the infobox could use the option of sub-sections. Already the Names and NIOSH use them in some form. However, so far with the Lethal data we are talking about, it is not right. The examples use subheader as "Lethal dose". That is just a grammatical construction to move words from the label (lefthand text) to a common row. The true grouping that might deserve a subheader, would be named like "Lethality" (or "Lethalness"?). We could explore that route, but immediately we see that this does not reduce the wording per data row enough (we'd still need something readable like a label '(Lowest published [lethal] dose) LDLo': no useful text-length reduction).
 * Apart from this, building a good subheader option takes some serious time (follow Infobox habit, apply for Names and NIOSH too, keep mobile view in mind, ...). This surely could yield a result, but after a longer development time. To add those two new parameters LCLo and LDLo more quikly (so that requestor Emily can add the data), I repeat my earlier proposal to use shortened wording for these not the full 3-lines definition wording. But hey, I can't enforce this, but I ask you all to reconsider this as a speedy solution. -DePiep (talk) 13:21, 5 June 2015 (UTC)
 * Preparing other changes to . This topic's demos (the sandboxes) are temporally disabled (demos won't show intended meaning). Expect days not weeks of disturbance. -DePiep (talk) 23:14, 6 June 2015 (UTC) - REstrored the demo. -DePiep (talk) 09:09, 9 June 2015 (UTC)

Hi, I'm really sorry I lost track of this discussion. DePiep, I think the shortened wording is okay as a quick solution to get this information in sooner rather than later, and subheadings can come later. Thanks so much for all your work on this. Emily Temple-Wood (NIOSH) (talk) 18:33, 16 June 2015 (UTC)
 * i.e. support for shorter wordings by OP. Will imply this shortly. -DePiep (talk) 18:36, 16 June 2015 (UTC)
 * Again, about bad target links. At the moment, the target links (lefthand side) are, irrespective of the label text shown:
 * LD50 &rarr; Median lethal dose (live)
 * LDLo &rarr; Lowest published lethal dose (R to Minimum lethal dose)
 * LC50 &rarr; Median lethal dose (live)
 * LCLo &rarr; Lethal concentration low
 * My comments:
 * LD50 -- OK
 * LDLo -- No definition of LDLo. No notion that LDLo is/is not LDmin.
 * LC50 -- Not to subsection like "LC50". LC50 is only mentioned sideways, not even a complete paragraph. Looks like LCt50 is more signifying.
 * LCLo --Sloppy lede. Article title not present in bold.
 * Over all, why are the definitions not written more parallel? Sure the two Lo's must mean something similar, but that doesn't show in the texts. Same for C and D. I repeat, if the target definitions are this sloppy or absent, we should conclude it's not worth mentioning that data in an infobox at all. (Options: we can consider rewriting and adding paragraphs, merging, use a #-link like  by sectiontitle or by anchor). -DePiep (talk) 12:42, 18 June 2015 (UTC)
 * Yeah, these articles need work. I need to run shortly but I think the solution is to have an article for "lethal dose" and then 4 subsections explaining each one. I'll implement that later tonight when I'm not on a time crunch. Emily Temple-Wood (NIOSH) (talk) 16:11, 18 June 2015 (UTC)
 * Sounds like a good plan (esp the no-stress part ;-) ). -DePiep (talk) 16:59, 18 June 2015 (UTC) + peek preview.
 * I took the no-stress part very seriously and took forever to even do a simple merge but all 4 articles are now combined into lethal dose. It needs a lot of work just in general, but a lot of that is due to the quality of the articles in the first place. It's an item on my to-do list but it may be a little while until I get to fully redoing the whole thing. However, I think it's good enough for linking from the chembox. Emily Temple-Wood (NIOSH) (talk) 05:35, 19 June 2015 (UTC)
 * Great improvement. Yes I'll surely use that in the Lethal subsection. (testcase). As you can see, I'm playing researching with the subheader-thing. I'm confident this will go forward (but not expected this week). -DePiep (talk) 10:04, 19 June 2015 (UTC)
 * Thank you so much! I really appreciate your help! Emily Temple-Wood (NIOSH) (talk) 01:40, 20 June 2015 (UTC)


 * Proposal finalised, see above and testcases. -DePiep (talk) 12:14, 21 June 2015 (UTC)
 * Ready for deployment. -DePiep (talk) 09:21, 22 June 2015 (UTC)
 * ✅. Parameters available. May I suggest to try to reduce bulk-of-data in this like in DDT? -DePiep (talk) 11:37, 23 June 2015 (UTC)
 * I can't thank you enough! Emily Temple-Wood (NIOSH) (talk) 01:11, 24 June 2015 (UTC)

Minor task force: parameter checking
In case some of you need a relaxing and life-fulfilling activity: please help emptying this maintenance category:. Atthe moment there are ~100 articles that have an unknown parameter (by typo, misunderstanding, wrong Section, ...). I invite you to try & fix a few articles.

Tip & help: if you and then, the offending parameter is shown at the top of the page, in red (plus its section like "Chembox Hazards"). All correct parameters are in this list. -DePiep (talk) 23:26, 25 June 2015 (UTC)
 * ✅ empty now. -DePiep (talk) 14:27, 26 June 2015 (UTC)

NIOSH and Lethal (LD50) data revisited
1. FYI: As Chembox is organised today, we easily track which articles use certain data input. That could help us. These lists are:
 * NIOSH (set): articles using (today ~500).
 * Lethal data (set): articles using (today ~700).

2. Note: To me it looks like the data entered can be too much or too detailed, for example DDT and I saw a 12-item list somewhere. I can not judge on scientific importance (well, being DDT ...). But for information presentation I suggest that it be summarized in the infobox, and maybe expanded in the text by relevance. We don't need to reproduce the complete source research! -DePiep (talk) 21:24, 24 June 2015 (UTC)
 * Ooh, it's good to know how many articles are using the data! (My nerdy heart just skipped a beat). I'm not sure the best place for these things is in prose, perhaps in a table in a safety section? I think having lethal data is really important and people are much more likely to come here than to NIOSH or whoever for it. (Sorry if this is incoherent, I just woke up from an accidental nap)  Emily Temple-Wood (NIOSH) (talk) 01:08, 25 June 2015 (UTC)
 * Yes, these numbers 500+700 are really great! (from &lt;200 total?). I don't want to discourage you editing at all. I do want to point, here in the open, to the 'relevance delution' for this encyclopedia. Of course, this exists for the whole infobox (with 500 parameters=potential data points...). I don't know a delimiter criterium, but somewhere there is a limit on infobox size. -DePiep (talk) 00:51, 26 June 2015 (UTC)
 * Definitely, and I think that's a problem facing the project with chembox in general. If safety data starts to become a problem, I'm sure we can find an alternative solution! :) (And hopefully Wikidata will enable units soon so we have another place to put data!) Emily Temple-Wood (NIOSH) (talk) 08:57, 29 June 2015 (UTC)
 * The safety data should stay in the infobox :-), but I think we should discuss some of the other parameters (especially all the indentifers and the pregnancy* and legal* (do not eat chemical compounds eat the "diluted" drugs). Christian75 (talk) 11:34, 29 June 2015 (UTC)
 * I am not proposing to "remove the safety data". I am questioning the size of the entries and its relevance. -DePiep (talk) 11:39, 29 June 2015 (UTC)

Template edits: Deprecation of parameters
I have prepared to step up the deprecation of parameters: Major changes imply required removal/change in code and in articles. Must actively be checked and edited. In practice, the articles are listed in maintenance category. Using AWB or AWB-script, the deprecations can be edited. Always, unknown parameters (=those deprecated) are listed in red when showing a.
 * Major changes
 * All temperatures: must have "Pt" suffix, as in "MeltingPtC". For MeltingPt, BoilingPt, FlashPt, AutoignitionPt. See full documentation at CalcTemperatures. (At last we can get rid of parameter name variants).
 * Data removed: EUIndex. See #Remove EUIndex.
 * Data removed: ExactMass (discussed 2012)
 * Data removed: EINECSCASNO
 * Identifiers EC-number, EC number &rarr; EC_number and EC_number_Comment.
 * Properties: MassRound &rarr; MolarMassRound (into regular name pattern)
 * Names: PIN_hidden, IUPACName_hidden (unused)
 * Identifiers: CASNos &rarr; CASNoOther; all eight: CASNos, ChEMBLs, ChemSpiderIDs, ChEbIs, InChIs, PubChems, SMILESs, UNIIs


 * Pharma: legal_ &rarr; Legal_ uc
 * Pharma: pregnancy_ &rarr; Pregnancy_ uc

These won't change showing, just changing parameter name to a preferred name. In general, no edit required; do when major edits are performed. May have been removed in earlier edits.
 * Minor changes
 * Hazards: NFPA-O &rarr; NFPA-S (NFPA-704 -Special, not -Other)
 * Hazards: NSFA_Ref &rarr; NSFA_ref
 * Hazards: ExternalMSDS &rarr; ExternalSDS


 * Explosive: ExplosiveV &rarr; DetonationV


 * Related: OtherFunctn, Function, OtherCpds &rarr; OtherFunction, OtherFunction_label, OtherCompounds (no shortcut spellings)
 * Some exhausted maintenance-trackings will be removed.
 * -DePiep (talk) 14:25, 7 July 2015 (UTC)
 * Processing. -DePiep (talk) 14:25, 7 July 2015 (UTC)
 * ✅. Tracking category empty now. -DePiep (talk) 21:36, 7 July 2015 (UTC)
 * You say no shortcut spelling, but OtherFunctn is a abbreviation for other functional group. And when its changed, it would be better to name it Related* which is the text in the infobox. Btw. Autoignition has earlier been changed to AutoignitionV, which is very strange when the name is either autoignition temperature or kindling point. It should be changed back to Autoignition. Christian75 (talk) 17:16, 7 July 2015 (UTC)

Template:Chembox EC-number and Template:Chembox EINECS

 * Sandbox demo available at Template:Chembox/testcases2. -DePiep (talk) 11:24, 19 May 2015 (UTC)

The external links in these subtemplates are broken. The respective search query at http://echa.europa.eu/information-on-chemicals should be linked instead. BTW: Do we really need both templates? --Leyo 23:09, 18 May 2015 (UTC)
 * Note: spelling should be consistent wikiwide, most likely "EC Number" table 2.2 (capital N, though ECHA uses lc in places). (see subsection below)
 * If I see this right, those registry systems (databases) and their institutions have merged & moved in recent years. Since today they lead to the same database (internet source), there is redundancy as Leyo notes. I propose to put both input options EINECS and EC-number into the single data row EC number with the link as given. EINECS then be declared deprecated (input keeps working OK, but not advertised any more. No need to edit articles). With this, the word "EINECS" does not appear in the labels (infobox LH-side column). Sandbox demo will follow. -DePiep (talk) 09:41, 19 May 2015 (UTC)
 * I indeed think that they are not both necessary and can be merged as DePiep suggests.
 * Regarding the link - I did not find any way to get a proper working URL with the EC-number as one of the parameters, it is handled by JAVA it appears. I am afraid that they are going to loose a lot of incoming links.  --Dirk Beetstra T  C 10:59, 19 May 2015 (UTC)
 * Yes, we want the link to open some data page (data sheet) for the substance. If we can not create that link, I think the ECHA site should be linked as a source: 200-815-3
 * -DePiep (talk) 11:11, 19 May 2015 (UTC)
 * Hmm, that would mean that every page needs the ref to be attached (you can not template references, unless that changed recently). Anyway, the primary reference is already accessible through EC Number.  --Dirk Beetstra T  C 11:21, 19 May 2015 (UTC)
 * The link I added would be added by the template, because it is the same for all. And a bit meaningless as a source. This is the URL when I searched for (ethylene) 200-815-3: (URL fails). If I can compose that URL from the EC Number input, it's a source (but still not a data sheet). -DePiep (talk) 11:32, 19 May 2015 (UTC)
 * That is what I mean, AFAIK, if you make a template containing the text " ", and transclude that template on a page, then the reference does not come through on the page (it does not appear in the list of refs), and likely will be parsed as a 'ref #1' by default (it is the first and only ref on the template). It would only come through if you put it as a plain link in the template.  --Dirk Beetstra T  C 12:20, 19 May 2015 (UTC)
 * Our preferences, by prio: 1. Automated link to a data sheet. 2. Automated reference link to the source. 3. free input by editor. To facilitate option 3 I'll add EC-number_comment for free text. -DePiep (talk) 11:57, 19 May 2015 (UTC)
 * I agree, though I think that 2 is not possible in ref-form - only in 'plain link' form (vide supra). For free input the comment field is good, and that can then take alternative references (though .. which).  I think between 2 and 3 we should just rely on the 'general disclaimer' for the infoboxes.  We do not need to reference data that is not expected to be challenged (WP:V), and if a specific case is challenged for some reason, then that is where the free-comment-field is for (the challenge in itself needs a reliable source to be verified, otherwise it is just a 'and I say it is 42'-type of challenge).  --Dirk Beetstra T  C 12:20, 19 May 2015 (UTC)
 * I'm confused. IMO when the external link (el) leads to a data sheet, we link the text. (e.g. ATC for aspirin: A01AD05). But when it is only a source defining the number, it should be in a reference superscript number:[1]. Both can be created by the template (we hope), no extra userinput should be required. -DePiep (talk) 17:44, 19 May 2015 (UTC)
 * The problem is not the preference, the problem is (was?) technical - A couple of years back when I tried it, I could not include a reference from a transcluded template .. of course, a http://example.org could solve the problem as well. --Dirk Beetstra T   C 03:24, 20 May 2015 (UTC)
 * Not any more. I've added links, see sandbox demo, just to test this (not proposed for live this way). Problem left is that we have nothing to link to (because we can not compose an URL using the input EC number). That would mean no external link at all. -DePiep (talk) 08:05, 20 May 2015 (UTC)
 * My point is in the top-left example - you link in the left column to EC number (should be EC index, but that is another part of the discussion below), telling you what it is and where you can find it and what it means for a compound, and in the right column of that box you have a reference to the search engine .. which in a way is just a tad better than 'go find it on google to see whether it is correct, here is a link to google'. I am still not sure whether that 'reference' there is needed.
 * Good to see that references can now be transcluded from templates, that has changed in the mediawiki setup. --Dirk Beetstra T  C 13:12, 20 May 2015 (UTC)
 * re 1: don't worry, that was just a wiki-technical proof to show: we can add ref links nowadays. I removed this goofy link already.
 * re 2: Yes. Since we can not link usefully, I propose to add no external link to the right-hand side for EC number. Because we do not have a useful one.
 * re 3: You say 'EC Index' not 'EC number'? Are you sure? These are different numbers (200-815-3 vs. 603-055-00-4 is [7] vs [9]!) I say this should be 'EC number'. More about 'EC Index' below, of course. Mistake? -DePiep (talk) 21:27, 20 May 2015 (UTC) re#3 added -DePiep (talk) 21:27, 20 May 2015 (UTC)
 * You're right, I am getting confused. EC number is what we are talking about here.  --Dirk Beetstra T  C 03:34, 21 May 2015 (UTC)
 * All right. Current sandbox demo = proposal by now. I will ask formally tomorrow etc.. -DePiep (talk) 21:48, 21 May 2015 (UTC)


 * Concluding, I think this is a point of consensus and so I propose to change the data row into (the example is ethylene):
 * EC number | 200-815-3

Note that the actual EC number is not linked. More tests are shown in testcases. pinged. -DePiep (talk) 14:05, 23 May 2015 (UTC)
 * Looks good, but I would name the parameter .   may remain an allowed alternative. --Leyo 19:13, 24 May 2015 (UTC)
 * OK, parameter is EC number. Kept for compatibility: EC-number, EINECS. Deleted: . Also added EC number_Comment in pattern of other identifiers. (I was using the don't-space habit as in ATCCode; it's arbitrary). -DePiep (talk) 11:56, 25 May 2015 (UTC)

spelling

 * About spelling, all mention of EC number (in the link) spell it EC number but tabel 2.2. Its a little bit strange to have the abbreviation EC Number, when the full title is European Community number (with small n). Christian75 (talk) 11:46, 19 May 2015 (UTC)
 * ECHA and it's predecessors are not very consistent (also not in writing CAS NR). Best is to find the defining document. So far, the hyphen is out. -DePiep (talk) 11:54, 19 May 2015 (UTC)
 * The capital on the N seems a bit silly, even Wikipedia itself is inconsistent there. IMHO, 'number' is not a given name, so no capital .. I think 'EC' is a good compromise for 'European Community' here, as that is what they use themselves as an abbreviation and it does not wrongly suggest something else (though .. Enzyme Commission number?).  The hyphen can be out in the display, though maybe the different variety-possibilites of the parameter in the chembox should include the one with hyphen.  --Dirk Beetstra T  C 12:20, 19 May 2015 (UTC)


 * Spelling should be copied from the definition by the source (i.e. an E.C. document), but we have not found that. Second option is to copy the EC (-institites') habit, which is mixed uc/lc in this case. I get the impression lowercase "n" more often. So I'll set it to "EC number". -DePiep (talk) 20:02, 19 May 2015 (UTC)
 * Sure the Enzyme Commission number "EC number" is creating ambiguity, esp. since it touches chemistry too. The actual number pattern differs, which helps a bit against confusion (for the initiated). WP:Accessibility and WP:DAB do not help me out in this. We could spell EC out here, in the label: European Community number, but for who is this clarifying? I think labeling it EC number is acceptable. -DePiep (talk) 20:02, 19 May 2015 (UTC)
 * EC number we'll write. Weird that the EC is not stable themselves. -DePiep (talk) 00:23, 22 May 2015 (UTC)
 * ✅. See #Template edits 7 June 2015. -DePiep (talk) 11:40, 8 June 2015 (UTC)

Parameters EINECSCASNO and EU index
I found two more parameters and data rows that are (possibly) related.
 * EINECSCASNO (for example, used in 2,4-Dimethoxybenzaldehyde; 2 uses in total).
 * Same issue: broken link, same EC Number identifier. Does not look useful to me. Propose: merge into   as above (with correct link), and delete this data row from {Chembox} completely.
 * Early conclusion: After edits and  Special:Diff/663063605 not used any more in articles. Following discussion below, this parameter+data row will be deprecated and removed. -DePiep (talk) 12:15, 19 May 2015 (UTC)
 * ✅ and deleted. -DePiep (talk) 11:40, 8 June 2015 (UTC)


 * EUIndex in section Hazards, for example propane. Data label is inlinked "EU Index". The input number differs from the EC Number, and we have no links (not in the label, not in with the data input). Can someone hint as to where this should link or lead? -DePiep (talk)
 * It was the EC number of 2,4-Dimethoxybenzaldehyde.
 * See CLP Regulation, Annex VI for definition of index numbers. Since it is not even given in the Registered Substances database, I don't think we need to have it in Wikipedia (but maybe at Wikidata). --Leyo 10:31, 19 May 2015 (UTC)
 * EINECSCASNO is indeed related, you can link into the EC-database using the CASNo .. Don't think it is necessary to keep using it, depracate, rename and delete.
 * EUIndex might be the third number in e.g. this document for propylene oxide ("EC Number 200-879-2; CAS-No 75-56-9; Index Number: 603-055-00-4). They describe here "INDEX number: The INDEX number (format XXX-XXX-XX-X) is a European number attributed to substances listed on Part 3 of Annex VI to CLP Regulation (List of harmonised classifications and labelling)."  I also see the designation "Annex VI Index number".  Ah, that gives: "Entries in Part 3 are listed according to the atomic number of the element most characteristic of the properties of the substance. Organic substances, because of their variety, have been placed in classes. The Index number for each substance is in the form of a digit sequence of the type ABC-RST-VW-Y. ABC corresponds to the atomic number of the most characteristic element or the most characteristic organic group in the molecule. RST is the consecutive number of the substance in the series ABC. VW denotes the form in which the substance is produced or placed on the market. Y is the check-digit calculated in accordance with the 10‑digit ISBN method. This number is indicated in the column entitled 'Index No'." in this document.  It is a classification of compounds (hence not an identifier, I am not sure whether this is by definition unique for a compound).  I guess we want to reproduce this number somewhere in the infobox (a google search on "603-055-00-4" nicely also includes Wikipedia as a result; though I must confess that I don't know how many people would search by this number - maybe people are interested in 'which compounds are classified by EU Index number starting with "603").
 * This brings up a possibility - do we want a sub-template 'classifications' for the chembox, containing this type of information (ATC-code, EU Index, ..)? --Dirk Beetstra T  C 10:59, 19 May 2015 (UTC)
 * Since the index number is not even given in the C&L inventory (for your example above), I don't really think it's worth having it in Wikipedia. --Leyo 16:17, 19 May 2015 (UTC)
 * When used, there should be an article EU Index (or a section in EC Number) for this. wrt a proposed new section "Classifications", I prefer not to separate classes but to keep them close to their specific topic (so ATC Code with medicine/drugs/pharmacology), as that is where a reader will search & expect it. This way, the extra information "ATC is drug related" is added with no extra cost. -DePiep (talk) 17:33, 19 May 2015 (UTC)
 * I think it should link to EU Index, which either is an own article, or a redirect to a section in EC Number (the latter case preparing for when s.o. converts the redirect to an article, though that is not a big issue since now the links are just one template, and the template is easily changed when article contents changes. --Dirk Beetstra T  C 03:24, 20 May 2015 (UTC)
 * Simple: we know that 'EC Index' exists in real life. If enwiki article/redirect EU Index / EC index does not lead to an article or section with substance, it is not worth mentioning in . -DePiep (talk) 21:38, 20 May 2015 (UTC)
 * It is that simple, but I think that EC Index should be mentioned on Wikipedia, looking around, the numbers are used by other organisations as well, so it seems that the chemical community finds it useful. --Dirk Beetstra T  C 03:34, 21 May 2015 (UTC)
 * I'm sort of waiting for you to create that link+text content, the lefthand label EC index (I myself am not familiar with that chemistry content). Then I'll make it link in the {Chembox} datarow. Choose capital for Index/index as you think best. -DePiep (talk) 21:42, 21 May 2015 (UTC)
 * I'll see if I can get to that. I think it is funny that you state here 'I myself am not familiar with that chemistry content'.  It is perfectly in line with your lack of understanding that the old order of identifiers was actually more ordered than you think, and puts into perspective your insistence that the order should be visible.  --Dirk Beetstra T  C 03:41, 24 May 2015 (UTC)

Remove 'EU Index' from Chembox

 * As may be concluded from the above thread, and supported by separate contributions by #here by, there is no usable definition for , nor is there a source that associates numbers with substances. All in all, this is not useful and sourceable data. I propose to remove data EUIndex and its datarow from  completely. -DePiep (talk) 14:19, 22 June 2015 (UTC)
 * prepared. EUIndex will be deleted. -DePiep (talk) 23:21, 24 June 2015 (UTC)
 * ✅ -DePiep (talk) 22:27, 7 July 2015 (UTC)

Metling_notes to MeltingPt_notes
Several of the Infoboxes are wrong because there is written a comment in "Metling_notes" which should now be "MeltingPt_notes". For example on BaCO3 there was Melting point = 811°C, but the note was "polymorphic transition". Or for SrCO3 the note was "decomposes". So often the comment is mandatory to understand the value. It is the same for BoilingPt_notes and Boiling_notes. --134.94.163.208 (talk) 13:45, 14 July 2015 (UTC)
 * You are right. This went wrong somehow: Articles using deprecated parameters like Melting_notes and Boiling_notes (even having them without value) should be listed in and should give a red message when shown in . This did not happen for Barium carbonate. I'll have to research this automated parameter checking. -DePiep (talk) 20:12, 14 July 2015 (UTC)
 * Parameter check does not function as expected in subtemplates (like Chembox Properties). I restored as accepted parameters Melting_notes and Boiling_notes (they will show). Those pages are listed in the category for edit. MAybe later the parameter check can function as expected. -DePiep (talk) 22:11, 14 July 2015 (UTC)

InChI: show just one, and how to show that?
Over at this Drugbox talk, raises this point: we should only mention one InChI (preferably the Std of course). A secondary issue is how to show that InChI, if at all, and how to handle external searches. Of course this is major to. For now, please discuss there not here. -DePiep (talk) 21:04, 16 July 2015 (UTC)

Duplicated SMILES
SMILES block is duplicated (after IUPHAR_ligand block and after RTECS), in Chembox Identifiers. --Jmarchn (talk) 16:27, 4 August 2015 (UTC)
 * Not exactly. SMILES is used twice: for Jmol-3D and for SMILES. But not repeated in the infobox. For example, see ammonia. -DePiep (talk) 22:46, 4 August 2015 (UTC)

Odor threshold
Hi, just a quick question. Is there a parameter for odor threshold? I'm not seeing it but I've been known to completely miss parameters in the complex chem-beast. :) Emily Temple-Wood (NIOSH) (talk) 17:17, 8 September 2015 (UTC)
 * Only odor exists (in subtemplate ). -DePiep (talk) 20:32, 8 September 2015 (UTC)
 * Thank you! :) Emily Temple-Wood (NIOSH) (talk) 03:17, 9 September 2015 (UTC)
 * ... or odour, but the language shown is always US-en not UK-en. I'm not sure uit is fit for the treshold data. btw, there is a ~complete list of params, makes easy searching. It is linked under All parameters listed, one of the top links in Navbox Chembox (=the documentation navbox, at the bottom of every doc page). -DePiep (talk) 06:52, 9 September 2015 (UTC)

Replace legal_NZ with legal_IN
I touched on this in the "German drug law" section but I'll present it formally here. Since there are 200+ countries in the world we cannot add the legal status of every country to the drug box. Therefore, we need some kind of consistent criteria for determining which countries to add. I am proposing we add those countries that will be useful for the highest number of en.wikipedia users. I believe the statistics available here may be of help. This shows that users from the US, UK, India, Canada, and Australia use en.wikipedia the most. Since New Zealand is much further down the list I propose we replace it with India. About five countries is probably sufficient for the infobox. This could be applied to both the chemical and drug infoboxes Sizeofint (talk) 23:44, 8 September 2015 (UTC)
 * Doesn't look like an improvement to me. Readership? It's replacing one crippled set of criteria with another one. Let me introduce the criterium: "where the applicable law is written in English" (at least this addresses the people affected by that law). Or: "Where the law is written in English, and the top 5 number of inhabitants". Or we can reorganise into groups: (four for example:) "Countries where this drug is free/OTC/Rx/illegal". (Read "and/or" for "or"). -DePiep (talk) 07:01, 9 September 2015 (UTC)
 * Why not create article "List of drug laws by country", and each blue link having the law (categories) + drugs + other descriptions (like formal category-change process, developments, provisional categories). Drugbox could have one link to that List of countries' law. At least it is unlimited into completeness for 200 countries. -DePiep (talk) 07:06, 9 September 2015 (UTC)
 * What criteria are we currently using? I am under the impression it has something to do with the number of native English speakers + presence of drug law article on en.wikipedia. In that case to be consistent per List of countries by English-speaking population South Africa and Ireland should be considered for inclusion because they have higher numbers of people who speak English as a first language than New Zealand. For Ireland we have Misuse of Drugs Act (Ireland) so there doesn't seem to be a reason not to add it. South Africa does not appear to have an article for their drug law. I don't really care what criteria we use as long as we have one that can be applied consistently. I feel that if we went the list route we might as well just link to the "Legal status" section of each article since that section should have the information anyway. The infobox should communicate information quickly and sending readers to another page defeats the point in my view. Sizeofint (talk) 18:19, 9 September 2015 (UTC)
 * re What criteria are we currently using? - A year ago it was like: US, UK, CA, AU, Other. It appeared to me (looking at the template's usage; I'm editing & following it); it appeared to me that the "Other" section was used quite often for NZ, so I added _NZ to the default input option list.
 * I may repeat myself, but since that German discussion here I agree that we have a mosaic set now. Or is scattered the word? (and I also think the alternatives so far are not great either). The more I think about it &mdash; I am processing &mdash; I support my own proposal ;-) for article "List of drug laws by country", which has a link to "Drug laws in US", "Drug laws in IN", "Drug laws in TO" which will describe the law & can mention (list) & wikilink to any drugarticle. -DePiep (talk) 20:37, 9 September 2015 (UTC)
 * Sort of oops: I only fired on your opening sentence. Now about your complete answer. It is about the same confusion: too much criteria-options for the drugbox-listing. One thing we can not circumvent: there are ~200 countries and so ~200 drug laws. I don't see a sound & stable (i.e. low-disputed or universal) reduction of this number. -DePiep (talk) 20:48, 9 September 2015 (UTC)
 * Regarding 200 countries = 200 drug laws for us to display: Is that what we're actually seeing? Is there a way for us to transclude the contents of  (i.e. legal_other) from all drugboxes into a list? Because if 2 or 3 countries are making up 80% of that list then we might want to think about making some extra legal-fields for them. It could solve most of the problem and buy us years until we have to look at it again. --Project Osprey (talk) 09:09, 11 September 2015 (UTC)
 * I think you mean Category:Drugs with non-standard legal status (678 P now). Note that writing "legal_status = Rx only" (no country specified) is bad. -DePiep (talk) 10:56, 11 September 2015 (UTC)
 * No not that. Upon closer inspection of drugbox (I don't use it often) don't think what I'm talking about actually exists. I had thought that in addition to 'legal_UK' and 'legal_US' etc there was a 'legal_other' field were people could enter data for any other country as a text string.

What to do about R and S phrases
As of the 1st June 20015 the old EU CHIP labels (better know as R Phrases and S Phrases) were replaced by the new GHS hazard statements. So the R and S phrases are now defunct and wont be appearing on SDS forms anymore - however, we still list a huge number of them in our chemboxes. What do people think we should do about this? Obvious options include leaving them, deleting them, or converting R → H and S → P (each R phrase is suppose to map to an H phrase, so no interpretation is needed, but there are a lot of chemboxes so unless so kind person writes a bot or knows a clever way of doing a mass edit this will take quite a long time). --Project Osprey (talk) 08:41, 10 September 2015 (UTC)
 * Mixtures that were already placed on the market before 2015/06/01 and not yet classified, labelled and packaged according to GHS are to be repackaged and relabelled by 2017/06/01 only. In addition, many products with R and S phrases will stay in households for quite a while. Therefore, it would be a bad idea to remove them from the chemboxes earlier than in 2017. In de.wikipedia, there is a notice shown for R and S phrases. It roughly translates as
 * Converting R and S phrases to P and H phrases is not always possible or does not always yield a meaningful result. I would rather gather the CLP data from the de.wikipedia articles that all cite a reference for them. To give an impression, Template:H-phrases is currently used in [//tools.wmflabs.org/templatecount/index.php?lang=en&name=H-phrases&namespace=10 385 articles], whereas de:Vorlage:H-Sätze is transcluded in [//tools.wmflabs.org/templatecount/index.php?lang=de&namespace=10&name=H-Sätze 7921 articles]. --Leyo 22:53, 10 September 2015 (UTC)
 * Yes, I should have realised that de.wikipedia would be more on top of this. Your point about old products staying in households is a good one, however very few of our chemboxes are about mixtures and pure compounds have already switched over to GHS. I don't think we should delete R and S phrases yet, but we will have to eventually. Part of the problem is that the change-over had been done quietly; I know about it because I'm in industry but I don't think many academics are aware that its happened and most of our chemistry editors on en.wikipedia seem to be academic. That might explain why only ~4% of our chemboxes have H phrases.
 * Is there any way we could transcribe all those H-Sätze from de.wikipedia to H phrases en.Wikipedia? The nice people from wikidata keep saying that such things should be possible but I've actually seen it done. --Project Osprey (talk) 08:47, 11 September 2015 (UTC)
 * To make it clear, products with DSD labels may be sold until end of May 2017.
 * I guess we would need the help of a highly skilled bot operator to get the GHS (CLP) labels from de.wikipedia. --Leyo 12:36, 11 September 2015 (UTC)

Formal suggestion for change—a newly revised chem infobox ref list… arbitrary break
The conversation seems to have ended with Bog's misstatement based on misunderstanding the issue, and then the last of DePiep's interjections (that I for one cannot usually understand). Ignoring the latter, and to bring this to a decision, I hope:

To say again, and contrary to Bog's content, a general citation list for the chem infoboxes (cited by many articles) already exists, here. My suggestion above, in short, is that we use this as a starting point, ordering it according to the order of appearance of chem infobox fields, then make all citations complete and clear, and then expand it as we need to be comprehensive. (Thus, we would set the stage for all remaining unsupported facts in the infobox to have inline citations in the article, with the further required references appearing in-article.) The suggestion that the general reference list appearing in so many boxes be ignored or removed, is (IMHO) too drastic of a change to the status quo. Otherwise, while I acknowledge the validity of the Beetstra comments that what is needed is change in behaviour, I note that changes in technology and tools often make behavioural improvements all the more likely (or unlikely, as at present). Now, please, comment on the very specific proposal to improve the existing chem infobox general reference list, as just described? Boghog, I ping you to be fair and civil; please try to reply in kind (and to fully understand what is being said before you reply). The proposal is clear and concrete, and per pages of discussion, anyone stating it to be an imaginary problem stands alone (or more precisely, with one other here). Le Prof Leprof 7272 (talk) 20:10, 10 September 2015 (UTC)


 * You have misquoted me. I never said cited by many articles. The problem is that you have not clearly stated what you are requesting. The order of citations is already taken care of automatically by the reflist template so I have no idea why you why requesting ordering it according to the order of appearance of chem infobox fields. Are you requesting specific citations for each chemical specific physical property (e.g. the boiling point of water is 100 °C) or a general "catch all" fallback citation to tertiary sources that would apply to most individual chemicals for a given type of property (e.g., here is link to a database that contains boiling points for a large number of substances)?  These are two very different requests and you need to specify exactly which you are referring to. Boghog (talk) 20:24, 10 September 2015 (UTC)
 * I also note that because of lack of resources, fully implementing the former in the near future is impractical while the later is misleading (there is no one source of physical constants that would contain all the necessary data) and therefore would violate WP:V (say where you got it). Boghog (talk) 20:43, 10 September 2015 (UTC)
 * Finally I note that the reference section in Chemical infobox is not meant to document physical constants per se but rather as a help to editors to find physical constants (hopefully with sources) that can be added to articles. This reference section is in Project namespace and not Wikipedia:Article namespace. Sourcing requirements and WP:V only applies to articles and not to projects. Furthermore, one cannot rely on sources in project name space to support statements in article name space. Boghog (talk) 21:14, 10 September 2015 (UTC)


 * The proposal is clear and concrete – Without specific examples, it is impossible to say what your proposal is. I have cleaned up the reference section that you were referring to so hopefully it is now clearer. Are you proposing to add sources selected from this general reference list as in-line citations to various fields in the chembox? (btw, I don't think this will work very well.) Or are you proposing something else? Please clarify with specific examples. Boghog (talk) 05:48, 11 September 2015 (UTC)
 * Below is a concrete example (mapping of sections of chembox to specific citations):


 * 1) Names
 * 2) Identifiers (Note: Not necessary to source entries in this section since these are self documenting (i.e., each entry contains a link to the appropriate external database.)
 * 3) Properties
 * 4) Density
 * 5) Melting point
 * 6) Boiling point
 * 7) Solubility
 * 8) Structure
 * 9) Crystal structure
 * 10) Point group
 * 11) Thermochemistry
 * 12) Std molar entropy
 * 13) Std molar enthalpy
 * 14) Gibbs free energy of formation
 * 15) Hazards
 * 16) Related compounds
 * 1) Hazards
 * 2) Related compounds
 * 1) Related compounds


 * Is this what you had in mind or something else? I personally think this is completely unworkable because there are so many compound specific exceptions, many cases where the citations would not be appropriate, databases that only apply to certain classes of compounds (e.g., organic vs. inorganic), etc., etc. Boghog (talk) 18:51, 11 September 2015 (UTC)

Help: exact InChI's please


Can someone help me out? For Proline, I am looking for the different InChI stings by R/S variant.

Proline has these CAS numbers:
 * 609-36-9 [RS]
 * 344-25-2 (R)
 * 147-85-3 (S)

But the article (chembox) does not differentiate the InChI's. I'd like to have the two R, S InChI's identified. (I need it for testing & exampling). -DePiep (talk) 19:47, 14 November 2015 (UTC)
 * Solved. -DePiep (talk) 08:21, 15 November 2015 (UTC)

Formal suggestion for change—a new chembox reference list
I propose for discussion, the following specific change: That we alter the status quo, working to create a new, thorough, infobox-correlated, complete-and-verifiable reference list for the chemboxes that is: After discussing this, we can wrestle with policy regarding what to do if the source of a datum is other than the one assigned in the new chembox reference list. Development of at least this would mean that if the "new chembox reference" is consulted, and the data not verified there, the reader/reviewer would know there is a problem to address.
 * 1) organized in order, according to the appearance of the DATA FIELDS in the chembox,
 * 2) thorough, with each field, standard and optional, having one corresponding reference, and
 * 3) scholarly, i.e., with each source being a good, complete, proper secondary sources.

Please, join me in discussing this specific proposal—including how it might integrate with earlier metadata discussions. Le Prof Leprof 7272 (talk) 22:39, 18 August 2015 (UTC)


 * in these earlier metadata discussions you were dismissive, non-cooperating, doing personal judgements, non-responsive, and maybe more. I'm not going to spend time on this. Just a simple point: why do you keep bolding your text, when it was explained to you that that is shouting? -DePiep (talk) 22:58, 19 August 2015 (UTC)
 * In no professional understanding of typography does bold mean anything other than emphasis. Yours is a singular perspective, but to ensure you do not feel disrespected, let me state plainly. When I use bold, I am not shouting. Le Prof Leprof 7272 (talk) 18:37, 21 August 2015 (UTC)
 * DePiep's perspective is not singular. I share it. Hint: if your posts were more concise, you wouldn't need bolding. Boghog (talk) 20:00, 24 August 2015 (UTC)
 * I afford you all the respect for this opinion, and in general, as demanded by your past behavior and the company you keep (here). Cheers. Le Prof Leprof 7272 (talk) 19:55, 10 September 2015 (UTC)
 * The way Wikipedia works is that people do things—proposing that others do things is usually unhelpful. Interspersing comments all over the place is also not ideal procedure. Someone might like to propose that holding the mouse over "boiling point: 100 °C" causes a pop-up message to display a reliable source with page number, but that's not going to happen unless someone comes up with a plausible plan and starts implementation. Why not work in a sandbox and post a short message without a belligerent heading asking for opinions when at least a mock-up is available. Johnuniq (talk) 01:42, 19 August 2015 (UTC)
 * I am sorry that you take umbrage at suggestions made in this way. (In every organization of which I have been a part, many very large and successful, similar means of making suggests are used. Major change only comes if the leaders are listening to all ideas.) But it appears at least some, below, are able to tolerate this, so lets see what they have to say. Le Prof Leprof 7272 (talk) 18:37, 21 August 2015 (UTC)
 * I had a non aggressive idea on how to deal with this in Wikidata context : imagine the datas are retrieved from Wikidata, a Wikidata statement is used to render an infobox facts, and that those how are not sourced on Wikidata are presented in a displeasant way such as with a refnec tag or in red like redlinks or whatever. People would be presented to a link to the statement in Wikidata like "add a source there", and when they did, the information is presented normally, with a "see the source" or whatever to see the original document. TomT0m (talk) 08:10, 19 August 2015 (UTC)
 * @TomT0m. WD is not able to provide values with units now so don't propose that solution because we can't provide a quick and simple solution now. We have a test scheduled in the next 3 weeks but right now we have nothing. Don't propose solutions which are only on the paper. Snipre (talk) 08:30, 19 August 2015 (UTC)
 * What's a few weeks or months in the project scale ? It's relevant to know the options before taking a decision that might take weeks to implement and might be to rethink from the start one month later. Nether to soon to communicate on a possible big change that can be a paradigm shift, people are generally slow to catch such kind of changes and its implications. TomT0m (talk) 08:49, 19 August 2015 (UTC)
 * @TomT0m. We have no idea when we will have a stable version of the numeric datatype with unit before the end of the year. The problem is if now the project Chemistry wants to start to use WD, they can't and no date can be provided to start a data migration. You sell wind. Snipre (talk) 13:09, 19 August 2015 (UTC)
 * selling wind
 * No I don't. The dev team of Wikidata is working on it and it's clearly one of their topmost priority with queries, they are about to have a test version. It's time to prepare the venue, and it's relevant in the context of the current discussion. TomT0m (talk) 13:37, 19 August 2015 (UTC)
 * Heu, you make a commitment here. The monolingual datatype is already developed from a while but we still can't use some languages. The dev team is working on units and will propose something, sure. Can they solve all the implementation problems in a short time, this is a bet I prefer to avoid. Snipre (talk) 15:20, 19 August 2015 (UTC)
 * In principle Wikidata is great, but I'm not sure how it would work with chemical infoboxes which have dozens of fields. Does anyone have experience with Category:Templates using data from Wikidata? Wikidata seems rather like the old joke of solving a programming problem with a regex—now you have two problems. The issue at the moment is how to ensure data in infoboxes is correct, verifiable and preferably directly referenced, and doesn't rot due to vandalism/mistakes. Would transferring it all to the elaborate scheme at Wikidata solve the problem or merely hide it? Johnuniq (talk) 10:22, 19 August 2015 (UTC)
 * It's a matter as how sources or lack of one is presented, as I suggested in my earlier post, that aspect of the problem does not really change. Once that is solved, the problem is "would it be easier to add a source on Wikidata or on Wikipedia" for a contributor ? Then I say that all have their own difficulties, but I would not say that Wikidata is harder than Wikipedia. Adding a source in Wikidata is a matter of clicking on "add a source", and typing a url with the "url" property, you should try it. Finding the right property to add the data is the equivalent to find the right infobox parameter is made easy by suggestions and typing a few letters, "num" for number of something for example will be enough in most cases. People should understand that pretty well. Now they have to understand Wikitext or where to put the url on the right part of the article, it's not that easy. The last part of my answer will be international collaborations : whatever the wikipedia language version they are reading or editing, they can contribute to Wikidata. Which means any Wikipedia can benefit of the sourcing efforts made in any other one, which is one of the most interesting feature of Wikidata. TomT0m (talk) 10:47, 19 August 2015 (UTC)
 * To be honest, while well intended, I think this proposal misses the point. It is already possible to add references to the data in chembox; either using reference fields already built into it, or by simply adding tags. Some editors do add refs and some do not; with access to the various paywalled services where this data is kept often the deciding factor. The problem has built up over time and will take a huge amount of effort to fix. Chembox is used on ~9700 pages, and if we include Drugbox (which I presume we'd also want to be fully referenced) then we're talking about ~15,000 pages. There are multiple data-fields to enter per page, but even if we limit ourselves to the most basic: mpt, bpt and density then we already need to find 45,000 references. As I said, there are only a dozen or so editors with the resources to do this and some of us are chipping away at it but it's going to take a lot of time. --Project Osprey (talk) 11:16, 19 August 2015 (UTC)
 * Osprey, all good suggestions, but Wikipedia is not Britannica. Britannica states at the base of its article page who it is that authored the article. Reading the Oxygen article,, one sees the name "Robert C. Brasted" at its base, and clicking on this takes you to a page that identifies RCB as "Professor of Chemistry, University of Minnesota, Minneapolis." That is, its claim to reliability is "authoritarian," in a very literal connotation of the word. Our claim, at WP is in the fact that our information is verifiable—not theoretically verifiable, but practically so. (I know of more than one faculty colleague, who on teaching the use of web resources, says of WP, "If a statement [or datum] has no citation, skip it. If it has a source, check it." And we should revel in this scrutiny, not bristle at it.) Even if all we do is say, for instance at the proposed new (revised) chembox reference list — "Melting points. For melting points, data are drawn from Source X (inorganic compounds), or Source Y (organic compounds)... and if from none of these, the source is indicated via an inline citation in the chembox." — we are doing readers a great service (in limiting the number of places to check before they have to conclude not to view the information as reliable). To leave it that the reader has to trust the value without a source, that is pretending to be authoritarian Britannica when our Pillars say our veracity lies elsewhere. Le Prof Leprof 7272 (talk) 19:25, 21 August 2015 (UTC)
 * Osprey hit the nail on the head. and reflist Wiki markup already takes care of points #1 and #2 on your list. If the number of sources for the chembox become very large, it may be necessary to segregate or collapse the sources, but this is trivial to set up. Point #3 is far from trivial and will take a substantial effort to fully implement. Wikidata has the potential to tap into the work of foreign language Wikipedias, but as explained elsewhere on this page, it is not yet ready for that purpose. Boghog (talk) 20:22, 24 August 2015 (UTC)
 * The question is not the possibility, the question is to know if the project Chemistry wants to go to the direction of sourced data (meaning each value with its specific source data) in the chembox. Again contributors will do what is done and if there is no "pressure" or incitement to add sources, very few persons will do more than others do.
 * The question of the number of current data is a false problem because the question is to know what you want. Do you want to have sourced data in the chembox ? Yes or no, and after we can start to speak about how to deal with the current data, with the problem of code,...
 * No body requires to have only data from well known references. You can still use data from the web but each time you add a value, add the source. You add a value from a web page, so use the template Template:Cite web. You add a value from Aldrich, use Template:Sigma-Aldrich, from Gestis, use Template:GESTIS, from a book, use Template:Cite book,...
 * Nobody is written a value from his memory and there are already enough templates to add the sources of the data if you want. But to see that happening you have to specify that from date XX. 201X the project wants to adopt a new sourcing policy and to provide the list of templates to use. Snipre (talk) 13:00, 19 August 2015 (UTC)
 * Well, the obvious answer to the first question is yes... But that has always been encouraged as well as being catered for by Chembox in the form of its various X_Ref fields. In terms of using wikidata; it sounds perfectly reasonable however I would hope that any changes made to Chembox's code (or at least the code that normal editors see) in order to make it more machine readable would not be done at the expense of it's human readability. If it becomes complex and confusing editors won't add new data.--Project Osprey (talk) 13:35, 19 August 2015 (UTC)

I agree that this again misses the point - it is possible to reference every single value in the chembox. And I agree that it should be. But the solution is not to suggest that we implement that - the solution is to implement it. One did a calculation that it is 15.000 chemicals that have the problem .. in the chem/drugbox .. the problem is that we have 221.000 articles lacking sources (and probably most are not even tagged), and every article has statements that need sourcing. This is not a chemistry specific problem. I have, above, agreed that the sourcing of the chemboxes could/should be better, I do however think that with the general references we are not doing even that bad - it is for, probably the large majority of, the data better than nothing at all. Whether we want to go there .. well, we should. Whether we can .. we once had a drive to have the identifiers verified and to get that data better and better - but that died (and actually, that would be a great source for the rest of the data if those were all correct, and that was the reason we started that (see the prose on User:CheMoBot) - get the identifiers right, and then check/source the rest of the data, much of which could be done/helped by machine). --Dirk Beetstra T C 13:39, 19 August 2015 (UTC)
 * Again : Wikidata :) (And I hope will back me up on this). I hope you're aware of this but Wikidata already have a lot of identifiers on items linked to articles. Bot work like User:CheMoBot is better when possible done in Wikidata. All wikidata's identifier are usable on infoboxes on the corresponding articles, with benefits that the bots of other people on other projects will do a part of the work. TomT0m (talk) 13:50, 19 August 2015 (UTC)
 * Ok, this time I can support you. With WD we can implement constraints with violation reports to help us to identify bad data. This is currently working well with identifiers because one of the main characteristics of identifiers is their uniqueness. In some way this is an improvement compared to CheMoBot because we can clearly identify some errors from an edit. See for example the current violation report for PubChem CID.
 * But this doesn't say anything about the use of the correct identifier. Here a check against external databases is necessary and we still miss a bot to point some changes on specific statements like identifiers. Snipre (talk) 14:30, 19 August 2015 (UTC)
 * But, the real problem is you can't say anything about whether an identifier is "correct" unless you have a set of criteria that defines whether the chemical that is referred to in the source database is the same as the chemical that is the subject of the wikidata item or wikipedia article. The InChI would be the "least worst" option for a large proportion of the compounds in Wikpedia/data as it is agnostic of any database and can be reconstituted to a structure (with certain caveats). This was the principle of s ChemMoBot work, the problem then becomes that you need to get editors to understand the importance of sourcing accurate structures. --The chemistds (talk) 16:11, 19 August 2015 (UTC)
 * Of course, and Interwiki links (I don't know if it is actually the case in chemicals) have mistakes, of course. But as the english article is likely to have been the reference, it's unlikely that there is that many inconsistencies with other wikis. Anyway, as long as the Wikidata item has a set of reliable and consistent set of identifiers to external database, this errors will likely be found and the wrong sitelinks founds :) This is a chicken and egg problem, and we have to start somewhere. It's easy to compare if the Wikidata statement about the id is the same of the Wikiedia article identifier. If it's not the same, then there is something to correct and maybe a conflict to solve ... that's Wikidata routine work. TomT0m (talk) 19:20, 19 August 2015 (UTC)
 * I've had discussions about WikiData - and I could (if I have time) rewrite CheMoBot to do it's actions on WikiData data (we could easily make for every verifiable field include a flag field for CheMoBot to maintain, problem is only for CheMoBot .. how to know that a certain field on WikiData is correct - do we need lists of 'revids' on WikiData to record it - after all, the problem stays the same: what if someone on WikiData changes the boiling point of water to 435 deg. C. a - who would notice, and b - how do we know whether that value was changed from something that someone else checked) .. The problem I foresee is the editing.  It is easy to just transclude all data from WikiData, so every page would just contain 'chembox', no identifiers would appear here anymore.  It is however an enormous leap of faith to first get new editors to understand that the data is not in our article here, and to get them there to edit (to find out where what is).  And monitoring - Here we have a good number of people monitoring together the thousand most important chemicals, there you need to 'watchlist' hundreds of individual identifiers per compound.  And do you have any clue how much of the data on WikiData at the moment is actually correct?  --Dirk Beetstra T  C 03:19, 20 August 2015 (UTC)
 * The Wikidata devteam is working on watchlist integration into Wikipédia, with options such as «show only Wikidata changes on datas used into the Wikipedia page»: There is already an options for monitoring Wikidata item changes in Wikipedia for items corresponding to your Wikipedia pages in your watchlist. It's disfunctional ATM, but in principle this address your concerns. Wikidata is not really another project, it's meant to be integrated into Wikipedia and others deeply — it already is as it handles sitelinks. You could also be surprised that some people could find Wikidata editing easier that Wikitext editing. A tooltip next to an infobox line «edit this data» and people will click naturally, and new editors won't even notice they're not on the same wikis. Old one may be surprised but it won't be hard to explain.
 * On data quality : you bot owners has the tools to compare and to import Wikipedia datas into Wikidata, so I would say oeverything is on your hands, in part of your bot migration (if you have time of course) :) On Wikidata we use a lot of reports : if a bot finds something weird he writes a report for a human to solve the weird cases. So I'll say at first datas will be no worse than Wikipedia one, then they will increase because of interwiki interlanguage human and robots cooperation through Wikidata, with more eyes to check the datas and watch for vandalisms. Wikidata has also a culture of cooperation with other databases, such as VIAF in authority control, this also might in the future be positive for chemistry datas if external big partners are found. Of course as number with units is not ready yet this leaves a few weeks or months to think about it :). TomT0m (talk) 08:44, 20 August 2015 (UTC)
 * @Dirk Beetstra. No element is correct right now. The main problem is data was coming from different sources (different WPs) where people thought it was a coming topic. But often they mixed salt forms with acid form of some molecules, they mix stereoisomer with the racemate, active substance with drug... So we have to clean the data first. Snipre (talk) 13:40, 24 August 2015 (UTC)

I'm not interested in this topic. But if anyone, the talkpager assaulting User:Leprof 7272 excluded, if anyone can convince me that even reading about this is useful, I'll act. -DePiep (talk) 22:43, 19 August 2015 (UTC)
 * Mdr. Perhaps my dear DePiep, just read what Osprey, Dirk, TomT0m, Snipre, chemistds… have been convincingly offering. This is a fantastic discussion. You needn't credit me for starting it, but do not disparage this clearly purposeful conversation.


 * Next, I very much appreciate Dirk saying that "it is possible to reference every single value in the chembox. And I agree that it should be." (emphasis added), and Johnuniq's later echoing of nearly the same—because it means we all seem to agree on the ultimate goal. The only question is how to get there, and I agree with the following themes of the foregoing discussion, that first, no major disruptive change should be made that makes it harder to edit, second, the answer lies in part, but not entirely, in an approach that uses Wikidata to solve connection problems between data fields and sources (which may however be the slowest-to-change component of the eventual solution, because of the work involved), and third, that the strategy of "just everyone, go source one unsourced datum at a time" cannot be the whole solution.


 * Next, I would point out that we are really not yet discussing the actual proposal that appears, as much as discussing its aim, motives, and ultimate steps (all fine)—but, anyone, why not revamp the general citations list, making it a page unto itself, and ordering it according to the appearance of the infobox fields?


 * Otherwise, nothing more from me as yet, except to say that, I would be glad to see a second generation proposal emerge for continuing discussion so that we operate with a concrete "motion on the table." Just my preference, to keep it focused. Otherwise, all fantastic give-and-take. Beyond my expectations at posting the first gen. proposal. If you come up with a counter proposal, please incorporate both the original and the discussion as much as possible. Cheers, Le Prof Leprof 7272 (talk) 18:37, 21 August 2015 (UTC)
 * See. Is what I say and why I say it: Leprof 7272 says how great he is. And, in the same bad line, is mentioned for having an argument (I hope), but actually Beetstra never ever performed a wiki discussion. Beetstra just keeps hammering. Is why I don't like/support this "discussion". And why I don't spend that much time on wiki any more. -DePiep (talk) 22:03, 9 September 2015 (UTC)
 * Let me add: this is what User:Beetstra wrote in this thread: "me and my fellow administrators to block every editor who will ...". So he and his admin friends will force anything anyway anyhow. Is Why I Leave Wikipedia. -DePiep (talk) 01:05, 10 September 2015 (UTC)
 * Oh, what a nice piece of cherry picking, User:DePiep. Pulling things totally out of context (and without 'reference').  I stand behind that policy based point I made there.  Can you now please comment on the subject of the thread instead of on one editor.  --Dirk Beetstra T  C 03:32, 10 September 2015 (UTC)
 * You said it, Beetstra. There is no "context" excuse. As for 'comment on the subject': I did. Shows you did not follow the discussion. -DePiep (talk) 22:31, 11 September 2015 (UTC)
 * As I said above, that statement is ripped out of context, the context being what we are enforcing. And in case you did not get that, it are the policies and guidelines we all agreed upon following that will be enforced there.  Now please go back onto the subject of this thread.  --Dirk Beetstra T  C 03:55, 13 September 2015 (UTC)
 * "why not revamp the general citations list ... ordering it according to the appearance of the infobox fields?" – as already pointed out several times above, reflist already does this. You have invented a problem that does not exist. Also, why create a "page on to itself"? This separates the data from the sources that support that data which is generally a bad idea.  Wikidata may eventually be a solution to the problem, but the mapping between Wikipedia articles and Wikidata items needs to be cleaned up first and regardless of where the sources are stored, someone needs to add them.  Who do you propose to do this?  Without concrete proposals and more importantly resources to implement these proposals, all this talk is nothing but hot air. Boghog (talk) 08:39, 25 August 2015 (UTC)

As pointed out by Project Osprey above, I prefer to simply have all non-trivial values referenced using tags, i.e. like in de.wikipedia. --Leyo 10:05, 25 August 2015 (UTC)
 * Yes. But why are all these distractions here? (not to say that the dewiki Chembox is better; I just don't have time to look at it). -DePiep (talk) 22:03, 9 September 2015 (UTC)

Pronounce parameter?
Over at drugbox we've added a 'pronounce' parameter. Should we do the same here? Sizeofint (talk) 02:08, 17 September 2015 (UTC)
 * Good idea, . But the problem is that when every time I propose & prepare such a thing, people like Christian75 and Beetstra come here, afterwards only, and then piss me all over. Beetstra is an admin (ok so far), threatening to use that force as an argument. WP:IWILW. -DePiep (talk) 23:54, 21 September 2015 (UTC)
 * This should go into the introduction, not the infobox. --Leyo 00:03, 22 September 2015 (UTC)
 * , have you seen the discussion about this at Template talk:Infobox drug? I think the reasoning would apply here as well. This has also been implemented for some time at Infobox element. I think it could make the lede clearer. Sizeofint (talk) 01:19, 22 September 2015 (UTC)
 * I have found your changes useful DePiep, perhaps we can engage them earlier. I will make a post about this discussion at WikiProject Chemicals. Sizeofint (talk) 01:27, 22 September 2015 (UTC)
 * Did you link to this discussion before? ;-) Also, I haven't seen an example of an article where this parameter is set.
 * IMO the box is too long compared to the length of the text. This imbalance should not get larger. --Leyo 13:24, 22 September 2015 (UTC)
 * Amphetamine and Strontium are examples. We do have to weigh the cost and benefit of the parameter. I think it is worthwhile because I'd like to keep the Chembox and Drugbox as closely in tune with each other as possible. Sizeofint (talk) 16:15, 22 September 2015 (UTC)