This is an archive of past discussions about Template:Chembox. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Probably, and even id it was "new", it's not an appropriate attribution - if we'd tag every new change in Wikipedia as such, then that term would become the tribble of Wikipedia... Mikael Häggström (talk) 16:22, 30 April 2011 (UTC)
Once upon a time there was {{Chembox}} and {{Chembox new}}. Chembox new was the non-table version of the chembox, while chembox was written as a substituted table. We had I think ~ 30k articles so the changeover was not instantaneous... I'll fix the documentation and search for further instances, but if you see it please let me know. --Rifleman 82 (talk) 02:50, 1 May 2011 (UTC)
Missing decimal-places in calculated molecular weight
When using the individual element fields, the molecular weight chembox entry is calculated automatically, rounded off at two decimal places. Looking at Bifluoride, however, it appears that trailing zeros are dropped from those decimal places (it reports "39" not "39.00"). I don't have time right now to dive into the template spaghetti to see where it's actually losing the precision. DMacks (talk) 21:18, 19 April 2012 (UTC)
There has been a discussion at Wikipedia talk:WikiProject Chemicals#Exact mass about disabling the parameter Exact mass from the Chemical infobox template for compounds. The reason is that naturally occurring compounds are mixtures of isotopic species, whereas Exact mass refers to a monoisotopic species and is useful only in mass spectrometry. The discussion there seemed to have a consensus in favor of removing this parameter, but since this is the talk page for the Infobox template I am now transferring the discussion here for further comments. Dirac66 (talk) 22:00, 20 April 2012 (UTC)
All articles which emply Chembox have a blank in the IPAC name, below the images of the molecules, even though there is the following in the source: 'IUPACName=...'.
Hiding all IUPAC names behind a collapsible list, just because a few ultra-long, multi-hyphenated ones (like the Violaxanthin example) break the infobox formatting, seems a little heavy-handed. In particular, to the casual reader, it suggests that the IUPAC name is not usually used, and is hence only shown if you specifically ask for it by clicking on a button. This inaccurate impression is further confirmed when the revealed name does not look obviously problematic, just a bit more formal. If no fully automated solution to the formatting problem is possible, perhaps the default should still be to display the name, but with some way to override the default in the Chembox source (e.g., using "IUPACNameLong = ...")? Hqb (talk) 18:02, 10 March 2009 (UTC)
Could we have a parameter like we have in talk page templates, "nesting=yes"; perhaps a "hide=yes" option? I agree with Hqb that the present situation is unsatisfactory. Thanks, Walkerma (talk) 23:56, 10 March 2009 (UTC)
It is not acceptable to hide all chemical names. Until we have an automatic version we should either use another parameter to decide if we hide the name or use css to display a scrollbar if the name length is too long (width, max-width, overflow). Cacycle (talk) 13:18, 2 April 2009 (UTC)
Drugbox, e.g. Fluoxetine uses the entire width of the infobox to display the IUPAC name. Seems however a breaking space needed to be added manually. We could do that, or could use a no-width optional break (& #8203;) to indicate the best place to break. Anyway, hiding the IUPAC is the worst solution. Lmatt (talk) 23:13, 15 April 2009 (UTC)
Breaking spaces are not necessary for the drugbox, but they improve layout for some of the more complicated IUPAC names. No-width breaks have been discussed and found a good idea, but actually they are not much used. I, too, would support using the whole width of the chembox to show the IUPAC name. --ἀνυπόδητος (talk) 10:02, 20 January 2010 (UTC)
Has this topic been dropped? It seems that the consensus was that the current default hiding of the IUPAC name is a bad thing. -- ToET01:36, 10 October 2009 (UTC)
Request for action: reinstate full IUPAC name as shown by default
Following the above discussion there seems to be a consensus developing that for several reasons it is a bad idea to universally suppress the IUPAC name by default, and that instead the IUPAC name should be shown by default, with facility for it to be hidden in specific cases as flagged.
If there are no rebuttals or disagreements lodged, then action should be taken to implement the above changes.
—DIV (138.194.12.32 (talk) 03:40, 20 January 2010 (UTC))
I have implemented this, add a parameter 'IUPACName_hidden = yes' to hide it by default. Will tweak {{chembox IUPACName}} further soon, though I would like to keep a 'hide' button there, so people with a really small screen can still choose to 'hide' names which we think are not too long, but who give problems for some.
I would not 'break' the names in some way, I am not sure how search engines (and not just google ..) etc. will cope with this. Though that problem is 'minimal' for IUPACName's, it may give problems with SMILES and InChI (where I am now tempted to implement the same option, show by default, hide as a choice). --Dirk BeetstraTC10:37, 20 January 2010 (UTC)
While the chemboxes are not adapted these with a large IUPAC name are much broader now. 'IUPAC name shown should be the default with an option for hidden if desired. May be something like this: "| state = collapsed" (must be editable).--Wickey-nl (talk) 14:45, 20 January 2010 (UTC)
By the way, why is it changed without looking to the suggestions above (Hqb, Walkerma). And "using the whole width of the chembox to show the IUPAC name" seems a good idea.--Wickey-nl (talk) 15:02, 20 January 2010 (UTC)
I have for now chosen to make the name visible as a standard, with an option to hide it (the hide button), and with a box-parameter to hide it as standard for the long ones ('IUPACName_hidden = yes' in the body).
I have made it two rows, now. One of the longer I now found is Citrinin, which shows nicely. I find it a bit unfortunate that the {{Collapsible list}} standard shows its 'title' in boldface, we may want to remove that template and do it by hand. How does this look (you may need to purge the page to show the new format, or go to the edit-mode). I would like to see now some REALLY long names which result in really wide boxes. Any available? --Dirk BeetstraTC15:52, 20 January 2010 (UTC)
ID .. hmm .. I see the problem. We have 'CAS Number', 'EC Number', 'UN Number', 'RTECS Number', which all make sense, for ChemSpider we say 'ChemSpider ID' (I think that Antony would use that as well, though), but then we don't have it for PubChem .. should it then be PubChem ID/Number as well? --Dirk BeetstraTC14:54, 21 January 2010 (UTC)
Systematic name is often used as synonym for IUPAC name. But yes, there is a difference. Just remove ID. It has no function. For all items one word.--Wickey-nl (talk) 15:03, 21 January 2010 (UTC)
I've come accross a bug in the chembox when it displays left and right images, see Glucose and Fructose for examples. When the two images have different heights, the shorter image is aligned to the top of the cell, rather than being center aligned as would be more attractive: it also seems to be left-aligned rather than center-aligned along the horizontal of its cell. I cannot even manage a quick fix to the problem by adding padding, as I haven't been able to override the common style for infoboxes: at least that's where I think the problem is, maybe I'm looking in the wrong place ;) We've recently changed the CSS class for the chembox (see above), and I suspect this might be the cause of the problem, but I'm not blaming anyone! I'd just like to see if anyone has ideas for the solution that seems to escape me for the moment :) Physchim62(talk)17:00, 2 September 2009 (UTC)
I have no ideas to suggest, but I do hope this gets done. I have to avoid putting two images of different heights side by side with each other. It would be much better if the vertical align was central. --Ephemeronium (talk) 16:25, 23 October 2010 (UTC)
I don't think that the 'showdescription=yes' is needed (one can toggle that on the page itself by clicking the 'Show text from Guidelines'/'Hide text from Guidelines'). Are there cases where one then would get a very large list, or is it still all contained in about a screen full (the example here is about a full screen for me)? --Dirk BeetstraTC09:13, 27 January 2010 (UTC)
Found an example with a longer text [2]. Most pages seem to be about the length of amitriptyline, but I've only checked about a dozen random examples. --ἀνυπόδητος (talk) 10:55, 27 January 2010 (UTC)
I'm not a specialist on this, so I'll ask 'what would the reader want to get'? I think specialists would have enough on the compact page, but that is not who we are writing for. However, how many non-specialists would actually follow this link to get more understanding of the subject (as opposed to mere curiosity of 'what does this button do'). --Dirk BeetstraTC11:37, 27 January 2010 (UTC)
New online tool for collecting ChemBox data
We have just connected a demo CGI to our portable Web sketcher at
http://www.xemistry.com/edit/frame.html
which we hope will be helpful for collecting chemical structure identifiers for the standard chemical infobox. Draw a compound (example: pyridine) in the sketcher, then press the "Compute Wikipedia Data" button in the form below. The tool will scan various Internet-accessible databases and format a cut&paste-ready chembox section for Wikipedia editing with the harvested data.
See Template:Chembox Hazards. The block starting with the line {{#if:{{{EUClass|}}}{{{RPhrases|}}}{{{SPhrases|}}}{{{RSPhrases|}}}| only displays if one of the params EUClass RPhrases SPhrases RSPhrases are present; and conversely, everthing after the pipe (|{{#if:{{{GHSPictograms|}}}) down to SkinHazard displays only if none of these params is present. No idea why it is written this way. --ἀνυπόδητος (talk) 17:20, 4 January 2010 (UTC)
Assuming I understand it correctly, I don't think it should function this way. There shouldn't be any reason for the variables to be dependent on each other like this. The markup is a little beyond me, but could you suggest an appropriate fix? -- Ed (Edgar181) 20:15, 6 January 2010 (UTC)
How is that? I removed the conditions in the main block, so that EUIndex, EUClass, RPhrases, SPhrases, RSPhrases, GHSPictograms, GHSSignalWord, HPhrases, PPhrases, MainHazards, InhalationHazard, IngestionHazard, SkinHazard, EyeHazard can all be displayed simultaneously if specified. You can try it out by inserting parameters into the template at the beginning of this section. The source code is at User:Anypodetos/Sandbox. Are you sure there was no good reason for introducing these restrictions in the first place? --ἀνυπόδητος (talk) 19:36, 7 January 2010 (UTC)
Your changes seem reasonable to me, but I don't know if there was a specific reason for the current coding. User:Beetstra and User:Physchim62 have done most of the work on the chembox templates, so I have asked them for their input (Dirk Beetstra seems to be on holiday, though). It's probably best to hear from them before making any non-trivial changes to the template. Thanks for your help. -- Ed (Edgar181) 21:02, 7 January 2010 (UTC)
The conditions are (were) there to discourage people from adding unsourced data about hazards. It is simply too easy to say that every chemical compound has a hazard, along the line of "all chemicals are dangerous and should be handled with care"! You can get nasty skin irritation from handling sodium chloride in industrial circumstances, for example, while potassium chloride is both a "salt substitute" and an essential part of the lethal injection used in most executions in the U.S. The EU criteria are far from perfect, but they are at least published and external of Wikipedia: for this reason they have been preferred over the judgments of individual editors for use in the infobox. Some chemicals have 'unusual' hazards (eg, hydrofluoric acid) but these should really be discussed in the article text rather than simply being in the infobox. Physchim62(talk)22:00, 7 January 2010 (UTC)
To take the example of 2-ethylhexanoic acid, it is really not useful to classify this compound as flammable when it's flash point is 110 °C (230 °F). No regulatory body would classify it as flammable, and you would have to take a blow torch to a sample to ignite it! The description of "flammable" simply doesn't concord with the definition that our users would give it. Physchim62(talk)22:18, 7 January 2010 (UTC)
OK, you're right, the use of "flammable" in that case may not be appropriate. But if it were flammable, do think it would be appropriate for the MainHazards field to show "flammable"? -- Ed (Edgar181) 01:55, 8 January 2010 (UTC)
the initial conditions have to be there, they are there to make sure that the module is only displayed if one of the parameters has value (some chemboxes do have the modules in them, but none of the parameters have a value, just to make it easy for others to give them one when they are found). The initial condition has to contain all of the variables that are generating something to display in the template. If it is not there it shows, like the box just above this paragraph on the right... --Beetstra (public) (Dirk BeetstraTC on public computers) 21:57, 7 January 2010 (UTC)
Note: I didn't remove the initial conditions of course; just the ones that prevent some of the fields to display if some others are present. I'm not saying I'm sure it should work like that – I leave the judgement to you. --ἀνυπόδητος (talk) 07:12, 8 January 2010 (UTC)
And while I am at it: {{CAS}} seems to behave strangely with the second parameter. Could somebody have a look at the example in the template's documentation – surely this isn't meant like that? ἀνυπόδητος (talk) 12:01, 7 January 2010 (UTC)
No, I disagree. CAS numbers are given out by CAS, and therefore they are linking to commonchemistry.org, just like pubchem should link to pubchem, chemspiderid to chemspider, etc. etc. --Beetstra (public) (Dirk BeetstraTC on public computers) 13:59, 8 January 2010 (UTC)
Yes, but PubChem provides (to my knowledge) results for all compounds with PubChem ids, while commonchemistry.org has only "~7900 chemicals of widespread general public interest". The first example I found is 115-93-5 which isn't on commonchemistry, but ChemSpider and ESIS retrieve the structure of cythioate. The CAS No. tool would provide people with more links to increase the chances to find something useful instead of "No CAS Registry Number® matched your search." --ἀνυπόδητος (talk) 22:36, 8 January 2010 (UTC)
True, but I still hope that the CAS will see that they get hits on those compounds which are not on their site, but do have the interest from Wikipedia users, and that they will also add them to their site then. And for me the argument that we link to the official place is stronger than that we link to a place where more information can be found (though the CAS site may give some information). Users will quick enough learn that the other sites linked to will give more and better information then the CAS site (which may be an incentive for CAS as well .. they could link through to relevant information on their side). --Dirk BeetstraTC09:41, 11 January 2010 (UTC)
Okay, you have convinced me :-) I just think it's a bit strange that {{chembox}}, {{drugbox}} and {{CAS}} link to three different places... I'll suggest that drugbox's link be changed. Cheers, ἀνυπόδητος (talk) 12:43, 11 January 2010 (UTC)
I created a solution for it, which may work, but which needs testing. You can now use PubChem for the main one, and next ones supply in PubChem1 through PubChem5; each can separately be verified, commented, etc. The rest can go into PubChemOther. Similarly goes for CASNo and ChemSpiderID. --Dirk BeetstraTC12:53, 20 January 2010 (UTC)
Great! You are fast. Redirect 6441444 to the subpage 6441444&loc=ec_rcs without changing the displayed number is probably too much. The fact that comments after the number may not be used with a space instead of  : is not obvious for the user. You have to know it.--Wickey-nl (talk) 14:26, 20 January 2010 (UTC)
We talk about two different spaces. The one between the two numbers is solved now. The other is between the number and the comment. A normal space will give a strange effect.--Wickey-nl (talk) 14:14, 21 January 2010 (UTC)
I have inserted two before the CASOther and CASNos fields, those may have been missing, but before the comment (CASNo_Comment) there was one already. Were you talking about the former two? --Dirk BeetstraTC14:45, 21 January 2010 (UTC)
Is it the examples (which you can edit, click the edit button in the green box, the documentation is not protected), or the code (which you can't edit)? --Dirk BeetstraTC14:55, 21 January 2010 (UTC)
PubChem is the main PubChem number, PubChem1 is the second, etc.
PubChem_Comment is the comment for PubChem, PubChem1_Comment is the comment for PubChem1, etc.
PubChemOther can be used for other information, or when one runs into a real excess. In the old version, that was where the additional PubChems were stored, they should in the end be converted into the new system. --Dirk BeetstraTC12:00, 12 March 2010 (UTC)
Thanks for your quick help. PubChem_Comment was not yet documentated.
Another question on the wrong place: ImageName does not do anything (I work on linux and tried with several browsers). Is it for a caption below the picture, or only for a popup?--Wickey-nl (talk) 12:53, 12 March 2010 (UTC)
ImageName is an old parameter in the old chemboxes. I don't think it does something at the moment, it could be revived, maybe. --Dirk BeetstraTC13:46, 12 March 2010 (UTC)
Can an alt text field be added to the images in this infobox? This allows for a description of the image suitable for screen readers, accessibility aids and text web browsers.
I can change the caption to images (like this), but it's not really correct as it changes the tooltip. I'd like to suggest that {{chembox}} and {{chembox image}} pass a parameter (ImageAlt perhaps?) to {{chembox image2}}. Part of chembox image 2 could be changed to [[File:{{{File}}}|{{{Size}}}|alt={{{Alt|{{{Caption}}}}}}|{{{Caption}}}]]. --h2g2bob (talk) 01:34, 9 February 2010 (UTC)
I have installed the four patches. I hope/think I did not include any /sandbox references, but please check if all is working now. Thanks! --Dirk BeetstraTC08:11, 12 February 2010 (UTC)
Items found in the French chembox but not in the English chembox
I'm trying to import French's fr:Polyéthylène chembox, but there are a few things that (I think) there is no equivalent in the English (and its clones :-) ) boxes:
TTransitionVitreuse - should be Glass transition temperature
constanteDielectrique - should be Dielectric constant
The data on chemical drugs where the chem box lists the "Mol. mass" in "g/mol". I believe the problem is the "Mol. mass" redirects to "Molecular Mass" wikipedia article, but it should redirect to "Molar mass" (which is measured in g/mol).
(First post in a discussion! Hope everything's in check, gonna work on figuring this Wikipedia functionality out in the near future) :)
In Starch I tried to add a caption to an image using the ImageName parameter, but it doesn't seem to work as advertised in the Chembox template documentation. Is there some other parameter to be used for captions? AxelBoldt (talk) 03:48, 6 April 2010 (UTC)
In analogy to the IUPHAR ligand parameter that has been added to the {{Drugbox}} template, I would like to request that this parameter also be added to the Chemical infobox. The code has already been added to the sandbox (see here and here) and a test case has been created (see User:Boghog2/Sandbox5). Thanks. Boghog (talk) 06:54, 5 May 2010 (UTC)
Five different editors have already supported adding the IUPHAR database link to the Drugbox template (see here and here). The complication is that many Wikipedia ligand articles transclude the Chemical infobox instead of the Drugbox. Hence for completeness, I have requested that the parameter also be added to the chemical infobox. Boghog (talk) 09:42, 5 May 2010 (UTC)
It is an informal policy that any info that can go into a drugbox should be able to be placed in a chembox, so yes, we should add this field. Physchim62(talk)09:46, 5 May 2010 (UTC)
{{editprotected}}
The last edit to this template, added a lot of use of /sandbox code. Could that part of the last edit be reverted but keeping the originally requested change. thanks. -- WOSlinker (talk) 18:39, 22 May 2010 (UTC)
What is the criteria for choosing which external MSDS to link in the externalMSDS field? Also, if the NFPA data from two different MSDS's contradict, which one should be chosen, and by what criteria? Thanks.—Tetracube (talk) 20:12, 1 June 2010 (UTC)
We had an awesome ad-hoc thing going with linking to oxford's MSDS service, but as of Dec 2011, that service has been discontinued (liability?)... I am loathe to link to chemical suppliers, but I have been linking infoboxes as I come across them generally to sciencelab.com due tot he comprehensive nature of those MSDS files which comes close to that of the oxford ones. The ICSC cards are good, but they don't function quite like standard MSDS, I feel. Is there perhaps a more permanent resource than chemical supplier sites that we can begin to move the oxford links to? (talk)Fourloves 22:15, 26 February 2012 (UTC)
GHS classifications
Editors who work in the European Union may have started to notice new hazard pictograms on bottles. The reason is that the EU is changing over to the Globally Harmonized System (GHS) for hazard classification and labelling. For pure substances, the changeover will be effective from 1 December 2010. The downside of this is that, from December, all the R- and S-statements in our chemboxes will be obsolete...
At present, there are three reliable sources (that I know of) for the new GHS classifications:
the EU CLP Regulation, which has about 3000 entries (some of them covering classes of compounds);
Editors can add GHS information to the Hazards section of the chembox already (see Hexyllithium for an example). For the moment, the section has been coded so that GHS info is not displayed if there is data in the older EU format: this is to try to avoid box creep. It would be easy to swap the two over in December, so that the older classifications are only shown if there is no GHS data.
If anyone is writing new articles or doing major updates, can you think to look for GHS safety data to include, as I'm not sure how much (if any) of the changeover can be done automatically. Cheers! Physchim62(talk)11:48, 22 June 2010 (UTC)
Please, this template is protected, would someone who is able to edit be so friendly to alter the prevalence of the R/S senteces and the GHS-phrases. When doing so, please add an entry for the pictograms too, the solution I used in 1,2-Dibromo-3-chloropropane and Acephate is somewhat noughty from a dictionary point of view.
Template {{GHSp} ???}} is intended to show all the GHSdata. The relavant data may be taken from {{SigmaLink}} (how to do so so documentation of SigmaLink.T.vanschaik (talk) 21:02, 23 May 2011 (UTC)
Incorrect HMIS information
Not sure how widespread this is, but the HMIS info listed for dimethylacetamide says that it's flammability rating is 0, just like water. NFPA 704 says that materials with a flash point between 38 and 93C should have a rating of 2, which is what DMAc is normally listed as (DMAc flashes at 70C). —Preceding unsigned comment added by 71.75.33.24 (talk) 15:18, 1 August 2010 (UTC)
European Medicines Agency links
The EMA's website for looking up drug licence details has changed, and with a much more complex URL. To aid maintence of {{Chembox}} and {{Drugbox}}, seemed easiest to creat a subtemplate to format the url. The code change at Drugbox is this, but I'm not familar enough to see where this goes for Chembox. David RubenTalk15:35, 22 August 2010 (UTC)
The chembox is much too long. I have even overlooked the second one in Pyran. The chembox is longer than the article itself. Chemboxes disturb the page layout. Believe me, not everyone is interested in the density and the standard enthalpy of formation of Glucose, certainly not every time.
Pictures and names are core information and should always be visible, but the other sections should be collapsed by default, like on the pages of Chemspider.
And please let the box show, after several requests, the captions of the images, to let the reader know which isomer is displayed, which kind of representation or that it are crystals.--Wickey-nl (talk) 11:11, 10 November 2010 (UTC)
Another possibility is to keep pictures and names only, along with a button/internal link to the bottom of the page. There, a frame with all technical data can be showed across the whole page width.--Wickey-nl (talk) 11:06, 11 November 2010 (UTC)
I've added captions, you can use ImageCaption, ImageCaption1, ImageCaption2, ImageCaptionL1, ImageCaptionR1, ImageCaption3, ImageCaption4, ImageCaptionL2, ImageCaptionR2.
I'm not sure about length of chembox. We could try and write collapsibility into the modules, but I'd like to hear more about that before implementing. (by the way, why does Pyran have two, if Pyran is a mixture then there should be one for the 'common' mixture, and not for the different consituents (they should be on their own pages)). --Dirk BeetstraTC11:16, 22 November 2010 (UTC)
Thank you very much. Captions should stay short and they can, because full names are not necessary. Since you choose new terms, existing names will not appear automatically. As for Pyran, it was not my work. Galmicmi changed it in may. Not a good idea; I shell reverse it.--Wickey-nl (talk) 13:35, 22 November 2010 (UTC)
Well, Pyran should not have a chembox, or a chembox ONLY for the mixture, and the two possible (3?) should have each their own chembox on their own page. --Dirk BeetstraTC14:35, 22 November 2010 (UTC)
And now there is no chembox at all... Should it be reverted to latest Drik Beetstra edit? It no longer looks like a standard chem wiki page. It's very nice to also see the .svg for hybridization locations, and the chembox is really the only reason some of use even visit wikipedia for chemicals. Fourloves 23:06, 28 February 2012 (UTC) (talk)
I chose new terms on purpose, the old ones are sometimes filled with a proper caption, but there are also several cases where it is not. Just to avoid page breakage I think it is better to start from scratch and use a term which is really suggesting that it is for the caption. I hope this explains. --Dirk BeetstraTC13:47, 22 November 2010 (UTC)
In glucose, there are two orgins to the spacing issues in the L1/R1 that I see. First, File:Glucose_chain_structure.svg is shorter than File:D-glucose-chain-3D-balls.png: each's caption is "same distance" below its image and the images are vertically aligned at the top of their cells, so the shorter image's caption floats up. Second, there is a <br> between the image and the caption, which makes an extra line of whitespace. Now just need to resolve "how to make it look better" (consensus on v-align for first and template origin of second). DMacks (talk) 11:10, 23 November 2010 (UTC)
(Without technical knowledge; may be just a stupid remark): If you align the images at the bottom the captures will get the same distance to the image?--Wickey-nl (talk) 11:51, 23 November 2010 (UTC)
No, the problem is, that there are, for some obscure reason, a varying number of 'newlines' between the image and the caption. Bottom aligning would put the caption at the bottom, and the image with a varying number of lines above it. --Dirk BeetstraTC11:53, 23 November 2010 (UTC)
Can the show buttons of smiles etc. be on the title line, if hidden (to make the box shorter), or does it give problems if two files/ smiles are given?--Wickey-nl (talk) 14:38, 22 November 2010 (UTC)
Bit more info, when opened, the link between the InChI and the InChIKey that belongs with thát InChI should be clear. Moreover, it would be good that they all open in one single click (i.e., if you open InChI, that you see all InChI's, that it is clear which one is the StdInChI (and which the other flavours), and which are the InChI<->InChIKey combinations). May not be trivial ... --Dirk BeetstraTC14:52, 22 November 2010 (UTC)
One button for ALL (more data) items would be the ultimate sollution for a growing chembox. Either a show/hide button or a simple link to a subpage, which would avoid the need for java! We can discuss about what should be always visible core information. The molecular formula is for sure and should even be higher in the box.--Wickey-nl (talk) 11:08, 23 November 2010 (UTC)
Well, that is the issue. The data is 'grouped' now by type. And for most Mw is an important thing, others might be more interested in exact mass, or in refractive indices or dipole moments or X-ray data. I could feel for collapsing the sub-boxes completely, though even that is .. questionable, as there will always be people, like me, who want to type 'benzene', and see immediately the boiling point without having to look for it. --Dirk BeetstraTC11:24, 23 November 2010 (UTC)
Consider the (far)most important user-target. I guess most readers are common people. Many will also be technically interested, though. The compromise is one click more to see all data at once.--Wickey-nl (talk) 12:03, 23 November 2010 (UTC)
Use minuses instead of hyphens for negative values
I've been adding InChIs to Chem/Drugboxes - and in many cases using the ChemSpider Wikibox to generate formatted data. Currently, this generates an InChI entry with the output "| InChI = InChI=1..." Which appears to be sensible on the basis that there is an entry title (| InChI = ) and then the appropriate data (InChI=1...).
At the moment the Chem/Drugboxes display this in an ugly way. It seems that they are programmed to accept data in the format "| InChI = 1..."
I would like to propose a rexamination of this approach. The "InChI=1..." is an integral part of the InChI itself - if you remove the "InChI=" part it will not be understood by the current InChI software/resolvers (I haven't tested all of them). Even the format that it is displayed in the Editing view "InChI = 1..." is not handled. I understand that the wiki box displays the InChI in the correct format, but I would suggest that it makes more sense to store the information in it's original usable state, rather than stripping out information then re-inserting it upon display.
I will be requesting that the ChemSpider developers change some of the output generated for the Wikibox data (to provide InChI keys and Std InChIs) I can ask them to change the format of the InChI output - but I would suggest that it might be better to change the behaviour of the Chem/Drugboxes themselves. --14:01, 28 November 2010 (UTC) —Preceding unsigned comment added by The chemistds (talk • contribs)
As an addition I was wondering if it might make sense to use the same formatting for the SMILES entry in Drug boxes and Chem boxes rather than having one with all caps and one with all lower case? It's not hugely important I just thought it might make sense for the formatting of both boxes to be as similar as possible. --The chemistds (talk) 14:14, 28 November 2010 (UTC)
SMILES is case sensitive (lower case = aromatic), so neither drugbox nor chembox should be all-lower or all-caps (and neither is as far as I see). --ἀνυπόδητος (talk) 14:19, 28 November 2010 (UTC)
Bit of a misunderstanding here. To clarify, in a Chembox a SMILES entry is prefaced with "| SMILES = " in a Drugbox one uses "| smiles = ", if you add an entry in a Drugbox using "| SMILES =" (upper case) it is not recognised as a field in the Drugbox and therefore not displayed. Just try changing the entry in the drugbox and previewing the result. It's not the end of the world that this difference exists. It just that greater uniformity between Chemboxes and Drugboxes might desirable. --The chemistds (talk) 19:22, 28 November 2010 (UTC)
OK, now I got you. By the way, a lot of parameters have different names in drug- and chembox (CAS_number/CASNo, ATC_prefix/ATCCode_prefix etc). The cleanest solution would probably be merging the two, but such proposals have never led to anything. --ἀνυπόδητος (talk) 08:37, 29 November 2010 (UTC)
Two points here:
1) InChI. I think I should say 'I have chosen' (we did not discuss this) to remove the 'InChI=' part from the InChI identifier and make the box handle that. ChemBox displays the InChI correctly, and renders it correctly:
And that is what Google will index, so searching on the InChI of benzene should show you this page (it is there, result number 27 in my case; chemspider fills the top positions). Also the internal wikipedia search (due to the format of the parameters) results in the same (except for the 2nd inchi, 'InChI1' etc.). Although recoding the box and letting it being done by the parameter would result in the same.
Reasons for omitting 'inchi=': a) it is being used in a mixed up way, there were more without than with. b) when using the 'inchi=' in the identifier, in the edit-box you see 'InChI=InChI=1/C6H6/c1-2-4-6-5-3-1/h1-6H' .. I have seen cases where not-knowing editors remove one instance of InChI= 'because now the parameter is filled twice, with a reasoning 'that can't be right' (and that breaks the InChI in the rendered text). For me it is fine either way, I'll go on for now adding them without, if the consensus changes, I would consider asking chem_awb to run and replace them, and adapt the code (CheMoBot will keep an eye if they get changed somewhere, unfortunately there are no functions to check if the contents of a parameter starts with 'inchi=', that needs to be done with bot-scripts or similar.
2) Indeed, as Anypodytos says, there are many parameters different between the boxes. A best would be to either generate a merger, or to 'clone' chembox to 'drugbox' (using a different colour scheme e.g.) and move all to the new format (or give all a chembox). But that never has gained much traction. A third option is to make the boxes listen to multiple parameters (we could program it in such way that both 'smiles' and 'SMILES'/ 'CASNo' and 'CAS_number' are giving the proper output in drugboxes and chemboxes.
ad 2) Generally, I'm not very happy with multiple names of params. It only causes confusion to newbies (Um, what's the difference between CASNo and CAS_number? Hey there is a documentation. It's 30 kB long...) and bots (if CASNo in template: cas=CASNo else if CAS_number in template: cas=CAS_number... wait, which name has the higher priority?) A possibility would be to change the param names of, say, drugbox, and have a bot rename the params in the transclusions. --ἀνυπόδητος (talk) 10:02, 29 November 2010 (UTC)
I agree with that (and I already have that problem with CheMoBot in a way. Which one is the verified one in InChI, InChI1, InChI2 ... for now I chose to ignore those, and verify StdInChI. Rename the whole would be an option (a nice task for chem_awb). --Dirk BeetstraTC10:07, 29 November 2010 (UTC)
@Dirk Beetstra - With respect to the formatting of the InChI string in the Wikibox - I understand the issues with the appearance of InChI= twice. And I see that the current approach works as it stands, I guess my point was that the solution seems to be to change the data (in this case the InChI string) and then apply formatting in the Chembox template to make it look like the original data, rather than retaining the integrity of the data and just applying a change to the Chembox template to avoid the inelegant appearance of the the data. There is nothing wrong with the current approach per se, its just that it might cause problems in the future if the data is to be reused (either in the Wikiverse or elsewhere). I thought I'd just point it out.
As for the point you might make about InChI1, InChI2 etc - shouldn't all of these be verified, so long as they also possess an accompanying comment/label? The two obvious use cases I would present are; Amino acids and sugars.
Often the names of the proteogenic Amino acids do not explicitly state any sterochemistry but in many contexts the L-stereochemistry (the naturally occurring biological form) is considered to be implicit - therefore it seems that there should be the CSID and InChI for the racemic compound and the L-stereoisomer (in which case one might as well include the details of the non-natural enantiomer as well, for completeness/comparison). One still needs to have the CSIDs and StdInChIs for both the racemic and the L-enantiomer structures.
With sugars such as D-glucose, you can have the open chain form, alpha and beta pyranose forms, and the alpha and beta furanose forms (nevermind the undefined/mixed anomer forms) which means that there are 5 (or 7) different structures each with their own CSID and StdInChI.
As it stands is it possible to use StdInChI1, StdInChI2, StdInChI1_comment, StdInChIKey1 and StdInChIKey1_comment etc in Chemboxes? I haven't tried yet. If not I'd suggest that they will be necessary - otherwise, there should be some guidance on how to choose which structure should be used to generate the StdInChI in the sort of situations that I describe above. --The chemistds (talk) 00:50, 1 December 2010 (UTC)
Regarding re-use .. as long as it is done here properly, if someone would source Wikipedia and then re-use the InChI's - it is just a matter of adding it again, or using a similar approach. Not that it is our problem, but this saves 6 bytes on every revid :-p
Hmm .. did not look at it that way. Maybe it is needed indeed, though one could choose to store one in StdInChI (of the 'main form' or something), the next in InChI, InChI1, etc., and the rest in InChI_Other. But we might want to expand on StdInChI in the end, indeed. --Dirk BeetstraTC15:08, 6 January 2011 (UTC)
Hi, I am the Chemical Curator for ChEMBL at the EBI, Hinxton, UK. We would really like to add a ChEMBL ID link to the ChemBox. How would we go about doing this?
Request for addition: additional hazardous material codes/class diamonds
G'day guys!
I'm currently in the process of re-writing the much neglected Hazchem article into something much cleaner, clarified, better referenced and more informative than the old article (which my working version can be found through my user page).
One thing I would like to raise with the project is the possible addition of Hazchem codes, hazard class diamonds (see: dangerous goods) and ADR HIN parameters so that the chembox, so that the chembox has a more worldwide perspective on dangerous goods, in addition to just the US' NFPA 704 diamond. A complete list of Hazchem codes and HIN's for a vast number of hazardous materials (or chemicals) by UN number can be found in the Australian Dangerous Goods Code which is available freely from here so finding Hazchem codes and HIN's isn't a problem. As I come across UN numbered substances, I'd be more than happy to include it's respective Hazchem code, class diamond and HIN.
Choosing a hazard class diamond is a little more difficult, although the ADGC specifies that "Substances (including mixtures and solutions) and articles subject to this Code are assigned to one of nine classes according to the hazard or the most predominant of the hazards they present." (pg. 34 of the ADGC, Vol 1, Part 2). Perhaps this can be added later when a more reliable method of classifying substances becomes available to us, as in a reference-able source.
Considering how the NFPA 704 diamond has been implemented in the chembox, perhaps the number identifying the class (i.e. "class_diamond = 7" which displays the generic radioactive class diamond) allows the easy allocation of class diamonds to materials?
As I have stated here, I think it would be better to change the text to "solubility in water". Solubility is as much a property of the solute as it is of the solvent. Furthermore water is a common term that does not need to be linked. Boghog (talk) 16:09, 18 December 2014 (UTC)
That's a better link. I am undecided. Note that {{infobox drug}} follows this thread. Since I updated that box yesterday, it now has water unlinked. But depending on the outcome here we'll adjust that of course. In the end, {{Chembox}} and {{infobox drug}} will be the same in this. -DePiep (talk) 12:23, 2 January 2015 (UTC)
I agree that aqueous solution is a much better target for the link. My preference would be the piped link "[[aqueous solution | solubility in water]]" as "water solubility" is slightly ambiguous (i.e., water can act as either a solvent or a solute). Boghog (talk) 00:08, 3 January 2015 (UTC)
#1 is simplest (least number of links). #2 is bad style (two adjacent wikilinks so it is not immediately apparent if there is one or two links). #3 is most accurate but somewhat redundant. I am leaning toward #3. Boghog (talk) 11:46, 3 January 2015 (UTC)
Would it be possible for each CAS No (and indeed for each value for every 'identifier') to start on a new line? Currently the text wraps, which leads to problems when the CASNo_Comment option is used, or even worse problems when it's used for some enties but not other. For example: Copper(II)_sulfate - I know the formatting behind chembox, so I can figure out what referes to what, but our readers most certainly can't. --Project Osprey (talk) 13:24, 17 December 2014 (UTC)
Yep, I will go into the sandbox shortly. Each CASNo to get their own datarow; makes a nicer list anyway. (I don't exactly understand what you mean by "worse problems", but could be solved by this already). Any other identifiers you are thinking of? -DePiep (talk) 13:39, 17 December 2014 (UTC)
I've only seen the problem with CAS No's as its more common for compounds to have several of them (hydrates etc) but I certainly haven't been everywhere so it may also effect pubchem, chemspider etc. This might create a new issue though; some people have been using <BR> to try and sort out the formatting themselves (i.e. Cobalt(II) chloride). --Project Osprey (talk) 14:00, 17 December 2014 (UTC)
Seems like a good idea to me, just insert a <br /> before the next ones. For the ones that already are 'fixed', they will probably still be better than the ones without, and that will clear out in time (maybe someone can figure out a search-trick to find them and repair them by AWB?). --Dirk BeetstraTC19:12, 17 December 2014 (UTC)
1. Aha, hadn't seen that indexes like |CASNo1=, |CASNo2= already exist: [5]. |CASNos= and |CASOther= is for the unstructured leftovers only.
2. Indeed, the <br/> should be (and so will be) added by {{chembox}}. Internally, Chembox will check & remove any <br/> that was added with the article input. I expect, that would have broken the CAS-link so it won't have happened that often. -DePiep (talk) 20:46, 17 December 2014 (UTC)
I'll take on the CAS numbers first. Question: currently we can enter 6 (|CASNo= and indexes 1–5 as in |CASNo3=). Today Magnesium sulfate uses them all, so I suspect that limit may be too low for some others. I can quite easily change that now. What number of CASNo's should we cover? (=max number of CASNo's in a chembox, with no need to use |CASOther=)? Note: this number should also cover each other possible identifier: SMILES, InChI, etc. In other words, the one max number to cover (say 8) must do for each and every indentifier. If there are 8 CASNo options possible/needed, and 11 SMILES, the number should be 11 for all. (Background reasoning on request). -DePiep (talk) 11:27, 18 December 2014 (UTC)
|CASNo6= and |CASNo7= added to the sandbox (that's 8 controlled CASNo's max). Building full support in {chembox} and by the bot. -DePiep (talk) 15:20, 18 December 2014 (UTC)
(edit conflit) Good question - the answer it appears is lots. Hydrates seem to be the most common reason for a page needing multiple CAS No's. The highest hydrates I've found on chemical pages are octadecahydrates (Aluminium sulfate and Chromium(III) sulfate). Assuming that CAS No's exist for each distinct hydrate, we would need a maximum of 18 (say 20 to make it a round number)... I admit that does seem like a lot, is 20 possible? --Project Osprey (talk) 15:31, 18 December 2014 (UTC)
Possible yes, practicable no. I'll build for indexes 0–9 (that's 10) all right. 0–7 (that's 8)
In my grander design, all identifiers and properties can have all these indexes (0–9 then): SMILES, InChI, PubChem, and also MeltingPt, ... . Then, any editor can make them correspond in one article: CASNo7=SMILES7=PubChem7=MeltingPt7 etc. Next step, an extra parameter |use_index=yes can be added and voila, every id has its sub-dentifier added ("R, S, (dodecahydrate)"). (For images there is another route). So that is why I want this index for all those params, and how to use it.
Now when we start this before having an chembox module (in Lua), this is nigh impossible for 20 indexes. We'd have to hardcode all 20 params for each (today there are 500 params already). But the Lua module can easily look for & find an index when it is present in the article (not by hardcoding the number, but by looking for it in the used parameters only). That Lua chembox I'm thinking of is not available yet (don't expect it this year ;-) ).
So, meanwhile we can start serving 10 indexes in core parameters, the editor can add & check carefully. More can be added in the |CASOther=, |CASNos= freetext parameters, uncontrolled. (I note that the two links only have two CAS registry numbers added, so there is no pressing need right? No editor is actually waiting for this to add 11–18 ;-) ). I must say that I do know about data structures, but I have no deep knowledge of chemical data definitions; I'm learning.
No, there's no urgent need for 18 or 20. If it were easy to do then we could future-proof ourselves, but as it is not then 8 should be plenty. Thank you for this. Project Osprey (talk) 22:03, 18 December 2014 (UTC)
What I am mainly afraid of here is massive table-creep. 18 CASNo's!? Of most compounds that have more than 5 CASNo's, only 2-3 are really important (e.g., generally: the water-free variety, the water-full variety, and sometimes a stable one inbetween. I know, MgSO4 could have 8 varieties (0-7), and one could possibly force to make all 8 (well, it looks like s.o. did ..) .. but I guess that about 3 of them have hardly any 'real life' meaning). I would really consider to have a not-too-high max built in, and let the rest be covered by the CASOther or CASNos fields. Remember, the page is about MgSO4, not about MgSO4.5 H2O, and in some cases that page may have it's own Wikipedia page (some hydrates are so important that they have their own page next to the parent salt-page). --Dirk BeetstraTC09:56, 20 December 2014 (UTC)
In a way, see it that the individual fact should pass our notability guidelines as well, ánd it should be verifiable that it really exists (is it a mixture of 6 MgSO4 and 1 MgSO4.7 H2O, or 8 distinct units of MgSO4.1H2O ...). Especially for CAS, it is not in their task to check how reliable the data is that assigns a certain formula to it. --Dirk BeetstraTC10:01, 20 December 2014 (UTC)
Sure, but that would be a Feature Article, where everything & their neighbors is clear out. Until that quality level, there might be a period where the inclusion/exclusion of substances is not stable or clear, the expected separate articles do not exist yet, etcetera: the editor might need some extra CAS mentionings. Or, more simple: the {chembox} could be applied into a List of MgSO4-related chemicals (my layman's example begs some belief, but the important word is: "List"). Or a List could be made from a bunch of stub individual articles.
In general, IMO the quality of edits should not be enforced by such a chosen template-suffocation. (That would be waaaay to difficult to document. The documentation saying: "If you need more than 5 CASNo's, you must create more articles" - ouch). In this situation, I prefer that grey-area substances & CASNo's are added, up for improvement (reasoned removal) later on. A removal could be into a new article too.This also covers the 'notability' check mentioned: needed is indeed, but not by forbidding addition; a notability talk can follow.
As for using |CASOther= for more related CASNo's: better not. Any CASNo worth entering or maybe worth it (the grey area), should be under control (bot). CASOther is for non-controlled data, outside of article topic (like |CASOther=See also [[(Mg,Cu)SO4·7H2O]] for 1234567-89-0). Or any other prose that does not need control.
(I note that I propose in the code a change of behaviour: all entered CASNo's are shown, there is no requirement to fill in |CASNo= first. All CASNo's are equal-ly important in this. And another simplification of documentation btw).
In short, I propose to not use a low number in the template to 'enforce' a quality somehow someway. Inclusion/exclusion of a CASNo for quality reasons is part of the wiki edit process. |CASNOther= shold be used for data that does not need a check, only. A wiki List article does not have a number restriction at all (so could have many CASNo's). With this, 5 is too low, ~8 I like. -DePiep (talk) 21:22, 21 December 2014 (UTC)
We have parameters |CASNos= and |CASOther= that can have input as free text(unchecked, unstructured). I don't see any benefit having two. I propose to merge them, and deprecate |CASNos=. (Technically: CASNos is removed from documentation, and categorised for edit [AWB?: change/merge into |CASOther=input]. When not used any more in articles, it can be removed from code). DePiep (talk) 20:08, 22 December 2014 (UTC)
Many articles with chemical infoboxes such as Teixobactin look really bad, with the infobox taking up 50% or more of the screen width (in this case, more than 100% of the screen width, and the thing doesn't scroll either, so overflow over the edge of the browser window is not readable) Is there some way to make all infoboxes scroll automatically when the exceed the display area of an article? (ie. before they start impinging on the sidebar that says "Main Page", "Contents", etc) (Better, if they start scrolling when they take up 50% of the content area width) -- 65.94.40.137 (talk) 01:35, 8 January 2015 (UTC)
No recent changes. As Andy describes, with me it is too wide when show (which is not the default/initial page status). (Firefox). AFAIK, long ago it was made this way keep the string 'findable', it is an identifier. -DePiep (talk) 11:55, 8 January 2015 (UTC)
Boghog Not fixed I think. The problem is that the very long InChI string (525 characters) is not wrapped. (this was done to keep this searchable web-wise, it is an identification). You can check this by unfolding the InChI data row, or by checking the "mobile view" (a link on the very very bottom of the article). With me, it was still tooooo wide.
I am changing that in {{chembox}}, but it needs testing before spreading it into 10,000 articles.
Meanwhile, I have added spaces in the long InChI string. That allows wrapping in this article. There is a lot of edit activity, so a nice page will help. After my solution change, I'll have another lookj here. (btw, your image edit looks like an improvement in itself, it caught my eye before). -DePiep (talk) 15:19, 8 January 2015 (UTC)
The problem is that there is no way to force-wrap a long string. It will only wrap at certain characters, but there is no way to say that it should wrap randomly at a certain max-width in the boxes. That is why it was hidden, but on systems without javascript it defaults to unhidden. Manually breaking the string is a solution, but I am afraid whether search engines would be able to find the full string if it is broken, and InChI is a string that one would Google for (some online databases have that hardcoded on their identifiers to enable finding other sources/databases). It is a recurring theme, where we either have to find a solution, or implement the one that has the least collateral damage (either a few viewers get a very broken page, or some viewers can't find the page). --Dirk BeetstraTC16:17, 8 January 2015 (UTC)
I wouldn't say that the addition of spaces will be too much of a problem as regards to searching for the InChI in Google - its known that Google doesn't handle long InChIs - this was the specific reason for the introduction of the InChIKey. A much bigger issue is that the spaces actually corrupt the InChI - if anyone wants to use the InChI - to generate a structure - search a database or any other task that the InChI is useful for you have to fix it, in such long strings it may not be easy to see that there are spaces causing the issue. --The chemistds (talk) 16:44, 8 January 2015 (UTC)
Still, if the InChI is broken on-wiki, even searching a sub-part of the InChI may not show up, and what determines what InChI is long - a 15-character InChI gives a 21-character-string (including the 'InChI='), which may for some pages already define as 'long'. Also using the InChI as an entrance into a search might end up in problems (external sites may not understand a 'broken' InChI. I am thinking, is it an idea to write a module that force-wraps long strings by just breaking them every #-characters without addition of hyphens? --Dirk BeetstraTC07:37, 12 January 2015 (UTC)
I am working on this and yes in css. And I am optimistic. Within a few days I'll put up a proposal on this page, to invite scrutiny. Note that, with other improvements in {{chembox}}, this involves 30+ templates in the {chembox} suite (30+ are in /sandbox development now, all related).
Halfway-results are in the /testcases pages for those interested, but in my proposal I'll ask for specific checks (like: check browsers, check mobile/desktop). In other words, you can help by checking my proposals, in a few days. -DePiep (talk) 10:48, 12 January 2015 (UTC)
I think we have tried things before like that, the problem is that some InChIs do not 'break' according to grammatical rules. We have been unable to set tablewidth (with Java(script) turned off) for Wiki-tables - on computers which have that turned off, it simply does not 'break' and shows the string in one continuous line (and the 'hide'/'show' function does not work, so it is standard shown), widening the table to page-width (or even wider and giving a horizontal scroll-bar). But lets see, it has been some time since this was last tried to be resolved. --Dirk BeetstraTC11:01, 12 January 2015 (UTC)
Done. The long InChI now line-break within the chembox, without a need for extra code (no spaces etc needed). Especially mobile view shows good now. Meanwhile, hot article Teixobactin has moved to a {{drugbox}}. -DePiep (talk) 16:18, 6 February 2015 (UTC)
New: Identifier linking to MetaboLights database
The MetaboLights database (http://www.ebi.ac.uk/metabolights/) was created by the European Bioinformatics Institute (EBI) with the aim of filling a gap in bioinformatics resources for storing and searching data from metabolomics studies. It is already the fastest-growing database at the EBI and is the recommended resource for deposition of metabolomics data by several leading journals including EMBO journal and Nature Scientific Data. The addition of a new Chembox link to the MetaboLights database would be of considerable value, providing not only structural information but also details of metabolomic studies where the compound has been reported including the study species, the metabolic pathway(s) involved in the production of the compound, reference spectra (NMR, MS) and literature references. See, for example MTBLC16530 (3-methyl-2-oxobutanoic acid).ChEBI Namrata (talk) 16:25, 14 January 2015 (UTC)
I have no judgement on whether it should be in. But for the case of adding it, can you describe or propose:
label text & links (in lefthand side in the infobox)
|parametername?= and data value to be added (by article editor)
Structure in resulting data value = article page result (visible text+link expected)
Any other notes expected? (reference, unformatted freetext, ...)
Preferred position in the Chembox: under which header, above/below which other data.
Just a note, if this parameter is to be added, please put it in the ChemBox as with all identifiers, the whole set of them, with possibility for bot verification, comments etc. We should however first see it's notability (articles should be created and stick). --Dirk BeetstraTC03:16, 15 January 2015 (UTC)
Agree. Didn't see yet what new data that database adds (next to combining existing data). The link in Chembox be a (automated) <ref>erence? I hope the future article brings clarity. -DePiep (talk) 09:57, 15 January 2015 (UTC)
As mentioned above, MetaboLights is the first open access, general-purpose open-access repository for metabolomic studies that acts both as an archive for metabolomics studies and a reference database for annotated metabolites. Metabolic profiling is an important tool for an insight into a biological functioning and perturbations induced due to various endogenous and exogenous factors. Linking a Wikipedia chemical or drug article to the corresponding MetaboLights entry would provide details about the occurrence of the compound at species level, the basic unit of classification, the Reference Spectra and associated metadata, biological roles, cellular locations, concentrations, and raw data from the metabolic experiments. See another entry, for example MTBLC16765, tryptamine, gives information about the different species in which the compound could be found, metabolic pathways in the respective organisms, spectral details including NMR and Mass and additional literature references. Additionally, the associated metabolic studies would also allow users to compare and analyse metabolomics data for different species on different platforms and techniques along with details about other metabolites that could be found under similar conditions.ChEBI Namrata (talk) 14:30, 15 January 2015 (UTC)
You would envisage that an identifier for MetaboLights (e.g MTBLC16765) in Chembox/Drugbox would directly link to the corresponding entry in the MetaboLights database analogous to the existing identifiers such as KEGG and ChEBI giving the additional details. Although the name "MetaboLights" itself might initially seem to apply to a restricted (metabolomics) community, the inclusion of spectroscopic reference data and experimental procedures in "MetaboLights" could be considered useful for a much broader user community including the organic and biochemical chemists.ChEBI Namrata (talk) 15:40, 15 January 2015 (UTC)
Andy, fuck off of talks and works I am doing. First you have to apologise or retract your other threads you disrupted & PA'ed. After that you maybe could contribute. Only then. -DePiep (talk) 00:04, 8 February 2015 (UTC)
re ChEBI Namrata: Big chance that KEGG will be removed some time per WP:EL and WP:LINKFARM. Skipping twice the request to at least create a wiki article about that database, does not support its suggested importance. -DePiep (talk) 18:00, 15 January 2015 (UTC)
I propose to change the presentation of the other names in {{Chembox}}. They can have their own section (-header). To the right is a demo version, with more in the testcases.
Changes
An infobox Section header is added Other names. It shows right below the images, where the names are already.
All line width is limited for all names to ~infobox width (max row width is 22 em). This affects long names. No more expanding into the lefthand screen side. Of course, this is a very important change (current situation could be called page destroying).
The order is changed into OtherNames, IUPACName, PIN, SystematicName. This prevents repeating names like 'Other' in subheaders, see next point.
Subdivision: the existing four data entries have their own sub-section. With the new order, there is no need to repeat section name "Other names" or "IUPAC name". The more below, the more specific a name is. IMO this is a clear structure, and makes a natural reading flow. Also when some data & headings are not present (see the variants in testpage4).
The subheader "IUPAC names" (-s) is pluralised when multiple names are detected. The editor can also enforce this by using |IUPACNames= (-s).
See below for the "hide/show" option. "show" is default.
Names are left-aligned.
Not changed
The four name entries are not changed. Data now present in the articles is shown unedited.
The names are right below the images.
No data, no header. In variants.
The |name= (infobox title, usually the article name) is not affected by this.
Note: the green color is used here to show it's a sandbox. It will be the soft yellow color when going live: .
Effects
The names, which can take up a number of lines, now are grouped under one infobox header. No suggestion as if they relate to a picture above.
Whitespace has disappeared, esp vertically. Sometimes a 20–25% height reduction in the names block shows.
Only one show/hide button in the names, not twofour.
All changes are checked in mobile view too. At least, this should not worsen (it doesn't).
Useful links
Testcases have the sandbox/live Chembox versions side by side (with same input). Some other changes like formatting are being developed too.
Any Remarks? The focus is on the new structure and setup. The show/hide issue is minor (& comment separately below, pls). The mobile view is available via the very last link on every wikipage. You might notice other changes in {{Chembox}}, they will be opened in an other section soon. If you want to add cases to the testpages, you can ask me (or: in your pet article, preview simply with {{chembox/sandbox ...). -DePiep (talk) 02:22, 16 January 2015 (UTC)
The hide/show button
The Other names section has a button "hide/show" to collapse/uncollapse the IUPAC names (three IUPAC data entries). The top row 'Otehr names' does not collapse ever. Default setting is "uncollapsed" (show all). Collapsing can be set in a {{Chembox}} by |IUPACNames_hidden=yes (or =collapse, =hide, =hidden). Existing parameters |IUPACName_hidden= and |PIN_hidden= will have the same effect. They are kept for compatibility.
Why hide?
Per WP:accessability, information should not be hidden (do not require extra user action, like a mouseclick). So the default setting should be "show". Also, in mobile view, the show/hide option does not appear and all will be shown always. In short, an article should show good in uncollapsed form.
{{Chembox}} has added these options because many names are technicxally and very long. That is, they should be on the page for e.g. search engines, but the reader would not need to see them. This is the (old) reason to hide them. However, since the wiki is approached by mobile device —which does not "hide" at all— that argument is moot. A modern rule would be: if it must not be shown, don't add it to the infobox! -DePiep (talk) 02:22, 16 January 2015 (UTC)
REL, short-term exposure, and international limits
Hi! I'm here with a suggestion for a couple small additions to the chembox. We already include the permissible exposure limit from OSHA, but NIOSH publishes the recommended exposure limit, which is often different from the PEL, as well as short-term exposure limits, which also typically differ from the PEL. Another parameter would be the IDLH, the concentration where the substance becomes "immediately dangerous to life and health". I think it'd be helpful to have these as extra parameters in the box. Also, per discussion on WT:CHEMISTRY, I'm working on getting international standards so we can include those in order to be less US-centric. NIOSH has collaborating agencies all over the place, so they shouldn't be too hard to include. Are there already parameters for any of these? (I'm still learning the ins and outs of the chembox, doesn't help that I'm bad with templates.) Please let me know what you think, and thank you! Best, Emily Temple-Wood (NIOSH) (talk) 06:15, 24 January 2015 (UTC)
I can not advise on whether we should add them (I'll read & follow this thread). I'll start a subthread to explore the what-if options (what-if we add them). I note that, since we already have US-relaterd PEL, another US-related data can be acceptable. Some country-raleted data (esp in {{drugbox}}) mention the country in the datarow ('CA'). -DePiep (talk) 17:30, 25 January 2015 (UTC)
Please spend time (your're payed I read :-) ) -- please spend time on the {{drugbox}} for this. Ask me if you don't see why that's important. -DePiep (talk) 19:21, 25 January 2015 (UTC)
I'm not sure what exactly you're getting at - though I will be looking at adding safety data via the drugbox. If there's something else I'm missing (only one cup of coffee today - clearly I need more) please let me know! Emily Temple-Wood (NIOSH) (talk) 19:58, 25 January 2015 (UTC)
{{Chembox}} and {{Drugbox}} are 'the same', but just have different accents from wiki history reasons. In the far future, they will be merged (same parameters, same meaning, just accents in prescriptions and so). So I suggest you take a look at how REL and IDLH would apply in sister {{drugbox}} (the same parameter treatment, full?). -DePiep (talk) 20:02, 25 January 2015 (UTC)
There is no Law that they will be merged, we just keep it in the back of our minds ("let's not make it more difficult to merge"). 'Algorithm' is just 'logic', what you do in your mind (and what others like me want to hear&learn from you). -DePiep (talk) 20:13, 25 January 2015 (UTC)
@DePiep: Hi, so I've been super busy the past few days and I'm just now getting back to this, sorry. Can we open a discussion to get consensus for adding these two values to the infobox? I'm happy to start an RfC or whatever. Best, Emily Temple-Wood (NIOSH) (talk) 05:17, 30 January 2015 (UTC) (moved this post to this section, is about adding yes/no. -DePiep (talk) 08:33, 30 January 2015 (UTC))
This thread is a correct proposal in itself. No RfC needed (that's for heavier policies & conflicts IMO). People can discuss & comment here. It's just that {{Chembox}} and {{infobox drug}} do not gain much talk traffic. If no one opposes, that's an outcome too. A few more days before concluding seems fine. (My personal opinion follows below). Oh, and stop saying 'sorry' for doing nothing wrong. Will make feel better — both of us. -DePiep (talk) 08:42, 30 January 2015 (UTC)
IMO: I have looked deeper into REL and PEL, and the agency NIOSH. Although US-only, and non-legal (as PEL is), the data is well-founded enough to add. In other substances (like medicine) we already have country-specific data (esp. {{drugbox}}:"AU, CA, UK, US"). Our REL article is much older that this proposal (another canceling out of possible COI pushing). Given that we have ~150 data rows already in {{chembox}}, often with multiple data facts, REL can have the benefit side of any grey area too. Todo: exact wording is to be fleshed out (see #Would look like, below), and {{infobox drug}} aka {{drugbox}} should strongly consider following. -DePiep (talk) 08:54, 30 January 2015 (UTC)
@DePiep: I'm okay with the wording of "PEL + foo ppm" for the REL, the reason I want to include it at all is because sometimes there hasn't been a legal limit enacted for a substance by OSHA (the legal agency) when there is still a recommendation from NIOSH (the research agency). And I haven't had anything to do with the REL/IDLH/PEL articles, though I do plan on eventually working on them to make them more accessible & complete. Emily Temple-Wood (NIOSH) (talk) 18:13, 30 January 2015 (UTC)
Would look like
Without prejudging whether the data will be added to {{chembox}} (discuss above), we can explore what it should look like. First suggestions:
"REL=PEL" I do not understand, and the template won't either unless you specify how and when that notion should be made (made visible in the article). In other words: how shold the template show "REL=PEL" depending on the editors input (in the article page)? And more more simple demo's to get the data feel. -DePiep (talk) 19:30, 25 January 2015 (UTC)
About last demo (Ethyl acetate): bad. When REL and PEL are the same --not by coincidence--, they should not be repeated. Please describe an algorithm (reasoning) on when/how to say: "PEL=REL", when relevant.
I'm not sure if there is an algorithm, perhaps there could be a parameter that says PEL/REL and use that when it's the same? This is all just data from the NIOSH Pocket Guide which doesn't give reasoning on why OSHA adopts the PELs they do. I'll ask around at NIOSH and see what people say. Emily Temple-Wood (NIOSH) (talk) 19:56, 25 January 2015 (UTC)
"TWA" and "ST" must be clarified, by either a link or an abbr tooltip: TWA. I'm still looking for the overlap (explaining the data repetition). -DePiep (talk) 17:41, 26 January 2015 (UTC)
TWA is the time weighted average of the exposure and ST is just short term exposure (<15 minutes, usually). The difference between a REL and a PEL is that the PEL is a guideline put in place from OSHA that must be followed, and the REL is just NIOSH's recommendation, which is usually more stringent than the OSHA PEL. Emily Temple-Wood (NIOSH) (talk) 19:21, 26 January 2015 (UTC)
Does the value for REL always match that of PEL? If they are always the same then we don't need two boxes (REL could be moved inside of the PEL row - REL is a recomended limit but PEL is a legal limit, so I think PEL should 'win' if we were only keeping one). --Project Osprey (talk) 13:18, 30 January 2015 (UTC)
@Project Osprey:@DePiep: So, the REL does not always match the PEL, when they do I think just having the PEL is fine. The reason I want to have both as parameters is for when there is no PEL but there is a REL. With the abbreviations, I'm happy to change 'TWA' and 'ST' to "TIme Weighted Average" and "Short Term" but if the {{abbr}} works that seems less clunky. I'm flexible. :) Emily Temple-Wood (NIOSH) (talk) 18:13, 30 January 2015 (UTC)
Working on {{chembox}}, but not exactly PEL & REL. Plan to. Notes:
note. When the editor enters "TWA" (plain text, uppercase), the template will add the abbr. Same for ST. Don't worry
Question: Is there a general source link for REL? (i.e., valid always). OR: CAn we contruct automatically a source link for example "Ethyl acetate" by creating:
[www.niost.gov.somepage Ethyl acetate] ? Ask me if this is unclear.
So unfortunately there isn't a general source link beyond [http://www.cdc.gov/niosh/npg/npgdXXXX.html] where XXXX is the 4-number identifier. I can't find a full listing of the data, just the alphabetical listing of chemicals with a link to the full data page. (that's here). I'm okay with putting the {{PGCH}} in each one. Thanks! Emily Temple-Wood (NIOSH) (talk) 21:00, 31 January 2015 (UTC)
1. The PGCH (pocket, pdf) is general and so could be (should be?) when there is PEl/REL/ILDH input. But that's generic, and could be on the LH side automatically. (If you add it to the REL input of Ethyl acetate, that is not good referencing).
2. Is the XXXX another internal id-number niosh uses? If that is the only way, we sigh and use that. But using a CAS Reg Number for the external link would be much better.
3. If the niosh XXX (4-digit) nume is the key, we'll add input parameter to enter like |REL_ref_id=XXX. What do you think? -DePiep (talk) 00:04, 1 February 2015 (UTC)
The PGCH PDF should be the PEL/REL/ILDH general ref. As for specific refs, the 4-digit number is an internal indexing number for the PGCH, NIOSH does put CAS numbers in each entry but it's not linkable if that makes sense? Here is the list of all chemicals included in the PGCH by CAS number, if that's helpful. There's no way to get from CAS number to PGCH entry besides that list, as far as I can tell. I will admit that the UI of the NIOSH site is not as friendly and easy to navigate as it could be and I may be missing something. Emily Temple-Wood (NIOSH) (talk) 00:19, 1 February 2015 (UTC)
Useful answer (and we'll save the flowers until it is working ;-) ).
Priority issues (we need to define the input data first & asap, so you can enter it in the articles):
1. So there is no useful search option with known id's (like CAS number).
2. Q: Shall we use like |NIOSH_id=0260 (for editors to input)? Then the link will go directly to [6]. If |NIOSH_id= is empty, the reference will link to the Pocket general page (search box) [7].
Less important issues.
3. See demo10, improved (don't worry about the line-breaking).
4. Q: Which name should we show: NIOSH, OSHA, CDC? (The most commonly known, most clear with this)?
5. Q: Is the sequence right? PEL-REL-IDLH?
6. {{chembox}} will replace TWA, ST with the appropriate text (linked, abbreviated, etc.).
@DePiep: Just to answer your questions - having the NIOSH_id parameter is super useful and not terribly onerous to input. NIOSH should be the name on the REL and IDLH since they're who sets it, not OSHA. The sequence is correct. Thanks so much! Emily Temple-Wood (NIOSH) (talk) 17:07, 2 February 2015 (UTC)
Oh and when entering PEL, REL data, do just type "TWA"; later the template will turn that into the link as talked here. Same for ST. -DePiep (talk) 20:48, 2 February 2015 (UTC)
Your edit fell in a crack: yesterday I removed all testing code (also the "use /sandboxes" settings), so that today code can go live. In this interval, {{Chembox}} /sandboxes do not work as expected (are no use for testing). That is what you saw! I just did an individual extra test on this demo you made, and it looks OK -- input shows as expected. (side topic: I fixed a temperature calculation here). And now: showtime. -DePiep (talk) 07:21, 6 February 2015 (UTC)
I am closing discussion part one, to implement the first version of REL and IDLH data.
Input parameters. All are optional.
|PEL=<!-- existing -->
|REL=
|IDLH=
|NIOSH_id=<!-- 4-digit, like '0260' for ethyl acetate-->
|NIOSH_ref=<!-- any <ref>...</ref> -->
These input parameters are guaranteed to be handled and shown OK. When entering data here, the article could require a References section. An early testcase demo is here.
Please do report any bugs and errors. Do not rise formatting or showing issues: they will be discussed later (few weeks?). Meanwhile, everyone can add data!
I am closing this because we must update the big {{chembox}}, because at the moment mobile views can be broken. We must solve that asap. -DePiep (talk) 12:03, 1 February 2015 (UTC)
New issues, after version 1
Implemented 16:24, 6 February 2015 (UTC). The PEL/REL/IDLH presentation has room for improvement. But data can be added. -DePiep (talk) 16:24, 6 February 2015 (UTC)
Proposal to add indexed identifiers (eg: |CASNo7=)
Note: proposed index numbers -6 and -7 will not be implemented (eg |CASNo6= and |CASNo7=). This is to limit template size and complexity. Text below shold be read accordingly -DePiep (talk) 11:11, 3 February 2015 (UTC)
I propose to add indexed identifiers to {{Chembox}}.
In short: {{Chembox}} takes indexes 1–7 for |CASNoX=, plus zero |CASNo=. The same for sixseven other identifiers like SMILES.
Infobox {{Chembox}} can show identifier |CASNo=. In addition, there are seven more indexed CASNo identifiers. See the list to the right. So {{Chembox}} can take and show 0–7 (eight) CASNo identifiers. Note that index number "0" (for |CASNo=) is not written or shown.
All indexed CASNo identifiers should be entered as a well-formatted CAS registry number, and nothing more. No formatting code should be added. They are shown in the infobox with a line break added (<br/>), when needed. All CASNo entries are bot-checked. So one can expect |CASNo7_Ref= in the article. There is no requirement for any sequence (it is not required to fill the numbers from 0 upwards; this freedom did not exist before, when CASNo= was required in the first place).
CASNo free text parameter
There also exists |CASNoOther=, which takes any text (e.g., an annotated list or prose). A <br/> might be needed in here. This parameter is never bot-checked.
All the indexed parameters are bot-checked. (7×9=63). They also take the |...Other= parameter to enter free text, unchecked.
Use the index
When the chembox has multiple substances, use the index. Make sure that |CASNo3= and |SMILES3= are about the same substance, and |CASNo3= and |SMILES2= are not. Treat index "0" the same way:
|CASNo= is |InChI= is |SMILES=
|CASNo1= is |InChI1= is |SMILES1=
|CASNo= is not|InChI1= is not|SMILES4=
When the indexes are used this way, you can add |use_index=yes to set a flag. That lists the article for further development using the indexes. At the moment, this parameter setting has no effect in articles at all. It only serves as a maintenance categorizing help.
This still is a good idea, but it is not tracked now.
Details
Deprecations
All -s parameters like |CASNos are deprecated. Use |CASNoOther instead
Parameter |CASOther is deprecated (because it has an irregular name pattern). Use |CASNoOther instead
Not for images
The image numbers (like in |ImageFile1= and |ImageFileR2=) are not indexes this sense. They do the row-positioning only.
(end of documentation)
Future with indexes
In the far future, {{Chembox}} can handle indexes even more systematically, I hope. For example, any image can be tied to a CASNoN index. And that can be shown or used in the infobox. But not tomorrow :-) . We'll keep that open. -DePiep (talk) 23:19, 26 January 2015 (UTC)
Comments
So in general: the Chemboxes listing multiple forms of a compound will become longer but better formated. Chemboxes listing only one form should see no major changes?... Love it! --Project Osprey (talk) 10:56, 27 January 2015 (UTC)
I have prepared a dozen or two of changes to {{Chembox}}. They are described below. There are testpages to demonstrate the differences. Please comment below. When things are stable, I can move them into life. -DePiep (talk) 23:43, 29 January 2015 (UTC)
Full Chembox subheader "Other names" added. Right below that is data |Other names=.
Then all IUPAC names in one show/hide box, with their subheaders: |IUPACname=, |IUPACnames= (new, plural), |PIN=, |SystematicName=
|IUPACName_hidden=y/yes/hidden/hide/collapse/collapsed to set collapsed box state (default:show, uncollapsed).
Change: the four name sets were all show/hide. Now there is one setting, for IUPAC name(s) only.
InChI and SMILES: limited width, forced line breaks.
The (long) names are now limited to infobox width (22em). This resolves a current page-breaking disruption (long identifiers run off-page to the left hand side. In mobile view, this is always visible because mobile does not have a show/hide option).
InChI input should not have |InChI=InChi=... added (will be double in output). These articles are listed for editing.
Footer: the extra formatting row below, a few pixels high, is invisible. rm horizontal top border.
Internal changes
{{Chembox entry}}, an intermediate datarow builder, is removed. This step is skipped.
Maintenance categories are simplified, and are {{main other|[[Cat...]]}} (categorize articles only).
The yellow subheaders are composed in the subtemplate, no {{!}}-code in the template any more.
PArameters like |CASNo_url= are not used in any result, so removed from internal code and from documentation (no categorization of other catch)
Ouch: bot params like |CASNo_Ref= did a double (nested) calculation! First input param {{cascite}} was processed (say into a green tick+maintCat; all fine). Then internally that value of |CASNo_Ref= was processed again for a tick (no extra effect). Did rm inner one, the template result of bot param input "|CASNo_Ref = {{cascite|changes|??}}" is presented directly. For all such identifiers (see new /format subtemplates).
Known issues
InChI and SMILES have a superfluous bottom border line (when no -Other data). Acceptable for now.
Bottom row (references) is ~2px too high (is where the row-width setting is kept).
Legal status (pharma): too much whitespace, see Chloral hydrate. ({{drugbox}} does better).
Pharma: presentation of Legal status, Pregnancy category, Licence were checked and improved. {{Drugbox}} is leading. More at the end of this section. -DePiep (talk) 11:36, 30 January 2015 (UTC)
Identifiers not indexed (=not changed, this time): |ChEBI=, |DrugBank=, ...
Done. Implemented in today's {{Chembox}} version. 16:25, 6 February 2015 (UTC)
Comments on list of changes
Looks good in general. I'm don't really like the transparent background for the title. Would it be possible to force a line break in "Solubility<BR> in water" to improve the formatting of the columns? --Project Osprey (talk) 11:57, 30 January 2015 (UTC)
Thanks for taking a check.
Title transparent bg: this is what most enwiki infoboxes do, it is the {{infobox}} standard. It shows in lithium ({{Infobox element}}) and Aspirin ({{drugbox}}). Non-chemical: War and Peace ({{Infobox book}}). That is where I took it from (for this old artisan handcrafted wikitable infobox). There is no urgent or topical reason to use a color. Could you consider this an experience of "I'm not used to it -- yet" (happened with the chemical elements change last year).
In general, grand wikipage design(ers) tend to bring in more white(-space) and less lines & colors. So if there is no reason to deviate from standard, I'd prefer to keep it transparent (~white).
Breaking line in "Solubility<BR> in water": can do, but is it needed? For me, the list of solubilities is a strain to understand already (I'm not not familiar with the topic; two similar words &tc.). A linebreak then adds a tiny bit to this mental grasping. Plus, in my screens, it does not push the column or infobox much wider if at all. In testcase ammonia, there are some others equally wide. You want to minimize the LH column more? Or the overall infobox (now 22em minimum)? Its about personal preferences now. -DePiep (talk) 12:26, 30 January 2015 (UTC)
You're right; adding the line break hasn't improved anything. I think the LH column should be kept thin as that improves the readability of the RH column - however that just my personal style choice. Regarding the transparent bg - this I can live with, after a while I probably wont notice anymore. --Project Osprey (talk) 16:46, 30 January 2015 (UTC)
OK & agree. It's 22em now total, with LH at 40% (set last March, unchanged now). Text can push a column wider. You want to see something else tried? -DePiep (talk) 17:13, 30 January 2015 (UTC)
Regarding the long InChIs etc. - you say they still break on mobile? I would then suggest again to render those through LUA ASAP, otherwise we get edits manually 'breaking' the InChIs (and others) again/still (I don't know if that is done still), and then we have to do a cleanup run later to repair them all again? --Dirk BeetstraTC03:34, 1 February 2015 (UTC)
No. Current live version breaks pages (bad). The new version does not break the page (good). That shows in the testcases pages esp. /testcases4, left hand side = sandbox. The max width for these is 22em (~regular infobox width)(Misunderstanding?: they do line-breaks as intended!). With me, they show OK in mobile view too (I test that by clicking the very last link on a testpage). eg [[8]]. Tell me if you see a broken sandbox! -DePiep (talk) 10:21, 1 February 2015 (UTC)
And yes, we can do a cleanup later (for unwanted <br/> in input). But what I'm changing is huge (40 sandboxes interacting), better not add that in the same change. -DePiep (talk) 10:24, 1 February 2015 (UTC)
I am closing the trunk for feature discussions. (Also as a note to self ;-) ). Time to implement the fix for broken pages, especially mobile views.
Note: proposed index numbers -6 and -7 will not be implemented. This is to limit template size and complexity. (eg |CASNo6= and |CASNo7=). -DePiep (talk) 11:17, 3 February 2015 (UTC)
Bot-managed templates like {{cascite}} are redesigned & recoded (7 verified identifiers + images). Will categorize more systematically "changed" verified fields. Required list of cats made complete (7, + 1=images). "images changed" still won't fill. Also "without CASNo" (x 7 identifiers) categories, filled by template not by bot. See new documentation at {{cascite}}. -DePiep (talk) 09:19, 6 February 2015 (UTC)
Some maintenance categorizations are filtered incorrect.
|DrugBank= and |ATCCode= can appear in Identifiers and in Pharmacology Sections (in the same form). From this, Category:Chemical pages without DrugBank identifier now has articles that do have a DrugBank id in Pharmacology Setion.
Paired images (left & right) do not show nicely even in mobile view. Not broken.
This is a bug and will be solved in a few days. |PubChem_Comment=foo will show as expected. No need to change (edit) articles for this. -DePiep (talk) 18:55, 8 February 2015 (UTC)
Updates (new version)
Follow-up edits, in preparation:
Make sure |PubChem_Comment=foo shows (bug, see above. All PubChem indexed comments)
Make sure |FlashPt_ref= shows (bug)
side-by-side images (L/R): in mobile view, the images do not show symmetric (instead, they are shifted to the left of the infobox). Had to restore deprecated code align=center in sbs-row. See esp. /testcases7images.
IUPAC names, other names, see esp. /testcase3. Last week, these were moved into their own subsection. More changes:
1. Remove any show/hide option. No reason to hide names. And anyway, in mobile view these are shown always. Unrelated to InChI-names showing/hiding.
2. Chemboxes with IUPACNames_hidden are categorized for a check, afterwards (& remove this deprecated parameter).
3. Restore sequence: IUPAC names first, 'other names' last.
4. Layout: to present long names more gently, they start indented (not in the righthand column).
Allow correct input like: InChI=IncChI=1/N123, but preventing double showing like InChI=IncChI=1/N123. This follows the InChI definition.
|KEGG= indexed 1–5, as other verified parameters.
|DrugBank= indexed 1–5, as other verified identifiers. All DrugBank input can be entered in both Identifiers and Pharmacology sections (as before).
Now all 8 verfied identifiers are indexed and completely bot-tracked for each index. They also take {{cascite}}-like templates for each indexed |_Ref=. E.g. |KEGG5_Ref={{cascite|changed}}.
I would suggest that parameter errors (and some syntax errors) in the chembox are tracked in a maintenance category. The compulsory and the optional parameters may be defined. All articles with other parameters in the chembox would be found. I introduced this for Template:GESTIS, where the articles with errors are now shown in Category:Pages with errors in Template:GESTIS (not yet fixed in order to visualize). --Leyo00:54, 5 February 2015 (UTC) PS. Visibility for errors in read mode restricted to autoconfirmed users.
You are absolutely right, there could be (more) parameter checking in {{chembox}}. The topic is very fit for that. However, there are a few complicating factors:
Chembox has ~500 parameters. Not all need a check, but reducing that to 200 or 100 leaves a big job still.
The bot User:CheMoBot also tracks certain parameters for verification. Keeping up that support takes attention too (and also serves as a parameter tracking aide).
{{Chembox}} and {{Drugbox}} share a lot of categories, subtemplates, design setups (though not consistently all), so we have to keep an eye on Drugbox params too.
This is what we used to call an "intricate template" (and that's an understatement).
{Chembox} is not in a Lua module now. Once it is in there, controlling data as you propose is much much easier.
I can note that these weeks I have been preparing many changes to many{{Chembox}} templates. When tests are stable, this will go live one of these days. This time, not many parameter checks as you propose are added. Other changes needed attention first (eg, the mobile page view can be disrupted in situations!). But I kept an eye on that goal all along. More on this is in talk sections above.
Some changes that are coming, and that might interest you, are: consistently fill categories like "articles without CAS Reg number", "articles with changed CAS Reg number".
Meanwhile (now that you are here), if you see disruptions in {{Chembox}} articles in the next week or so, you are invited to report them. My changes need all the eyes we can get. -DePiep (talk) 10:24, 5 February 2015 (UTC)
Module:TemplatePar needs to be given just a list of all parameters, which may be quite long (example). It will find e.g. misspelled parameters and syntax errors such as parameter name: instead of parameter name=.
If the template documentation is up-to-date, i.e. it contains all possible parameters, it's not such a hard work to add Module:TemplatePar. --Leyo07:19, 6 February 2015 (UTC)
We have Category:Chembox maintenance categories with 40+ specific maintenance categorizations. The parameter name: mistake you mention is covered in there. However. A parameter list you point to "which may be quite long" has only 100 params. As said, for {{Chembox}} that is multiplied by 5 (500 params). Then, we have 10 subtemplates must have that param check too (that's how it is). And all that for a misspelled param? And that still would not help against unwanted <br/> in input, or a misformatted CAS NR. So, let's first clean up those 40 categories. Then, next week we'll take another look. (did you see that the German {{GESTIS}} template requires another entering of the CAS NR?) -DePiep (talk) 15:48, 6 February 2015 (UTC)
Any reply to my answers? btw, I do like the German links. Inspiring. But changing your own topic again again to tell me what is wrong with {{Chembox}} -- no. I know. -DePiep (talk) 21:36, 6 February 2015 (UTC)
Tell me, honestly: which of the links I gave did you actually click & read & digest? Your answers here suggest a zero. -DePiep (talk) 21:42, 6 February 2015 (UTC)
Yes, I did not answer your concern about the number of parameters. I agree that there are many, but apart for the work of getting a complete list, I do not see a real problem here. Are you concerned about the performance, i.e. that the page rendering time would be too high?
No I am not worried about performance at all. It's just, it's complicated as in: those templates interact, and there is the CheMoBot working, and external chemistry databases definitions. And this time I did not review the image showings (almost not). Another worry is that there is little activity in the verification process. 50% of the chemboxes are redcrossed. And there is {{drugbox}} to look at, always doing things with the same stuff. Anyway, I think I made another cleanup, into simplification. -DePiep (talk) 17:30, 8 February 2015 (UTC)
I appreciate your contributions (I first thought an error happened: empty maint cats ;-) ). I'm not replying now to this last post of yours. It happened that up into Friday I put live 45 intricate Chembox templates I was working on for eight weeks. All interconnected, me having to research a bot behaviour, chemistry habits & external links, and an inherited Chembox setup. I liked it (it works, feels good today!), but I was not in the mood to read criticism on how to do well during these days. I already clicked those German dewiki links, and there are nice & great solutions indeed. But today I take a break, doing only the edits I like. Later, I might re-engage Chembox improvements. I was thinking, Drugbox can use a leap-frog to catch up with this one. -DePiep (talk) 20:46, 7 February 2015 (UTC)
Leyo, I am thinking about this: for every relevant institute, we create a top category: "Category:Chemical articles and CAS". In there are any CAS-related categories we have. It should not be about templates (not "CAS issue from {{Chembox}}", not "CAS issues from {{Drugbox}}"). It will be articles only (not anypage). Because, I grasp (I'm not a chemist) that these institutes and their databases interact heavily about chemical substances in many ways (also with wiki of course). Chemistry, medicine, hazards: everything relates. So why not have a category that gives 'outsiders' and us an overview from there: "Cat:Chemical articles and KEGG", with subs "Cat:Chemical articles that use KEGG"; "Cat:Chemical articles with a KEGG issue"? (existing categories, eg by the bot, will stay). -DePiep (talk) 17:46, 8 February 2015 (UTC)
As a side-note, have you considered asking WP:AWB permission? Looks like you could make good use of it. And in AWB, there is the pattern-handler WP:REGEX, worth researching. (also, without permission you can install it and wikilegal create page lists. Useful for me). -DePiep (talk) 08:24, 13 February 2015 (UTC)
I suggest that for consistency with IUPAC recommendations this should resolve as "Gibbs free energy", rather than "Gibbs energy". (For consistency with other items in the Thermochemistry section of the table, it should resolve as "Standard Gibbs energy (change) of formation", although personally I think that may be too much of a mouthful.)
—DIV (137.111.13.4 (talk) 03:03, 19 February 2015 (UTC))
Isn't that already there? Where did you see that other text? Today it shows, with |DeltaGf=some-input:
I suppose it could be re-pointed to [[Gibbs_free_energy#Standard_energy_change_of_formation]]; the chembox description could then be changed slightly to "Gibbs free energy (ΔGf˚)" (N.B. now with a f). --Project Osprey (talk) 11:50, 19 February 2015 (UTC)
Checked subtemplates are: {{Chembox Explosives}}, {{Chembox Structure}}, {{Chembox Pharmacology}}, {{Chembox Thermochemistry}}, {{Chembox Related}}. The other templates are to follow.
Note: if you Preview the article, a more specific error message will appear.
As you might have seen on the dewiki talkpage, I was having a headache or two to get the current options working (and we had to wait for this latest version; still open issues). The feature you mention could be a feature in the module itself. Given the other issues with {{chembox}} and {{drugbox}}, I'd rather not spend time on this.
Used in sub {{Chembox Properties}}. What change do you propose, and where? For the formula itself, I'd like to use {{Chem}} for all molecule formulas (when entered by |C=...|H=...|S=... etc.). Note, as it is used today, this formula setup also calculates the molar mass in {Chembox} (good to do through Lua then). Will take a look later on. -DePiep (talk) 19:18, 22 March 2015 (UTC)
So, it is only internal to {Chembox}, or am I missing something? (My opinion: if it is background/internal {Chembox} only, we better put it on the back burner). -DePiep (talk) 21:10, 22 March 2015 (UTC)
To template editor: This is a centralised talk page for template:Chembox* - thats the reason the edit request is requested here. template:Chembox Formula should be changed as discussed. E.g. [[Chemical formula|Molecular formula]] to [[Chemical formula]] Christian75 (talk) 21:08, 26 March 2015 (UTC)
Set to "answered=yes" (to 'pause') because requestor is stubbornly interfering with sandboxing proces. -DePiep (talk) 23:06, 26 March 2015 (UTC)
To template editor: This is a centralised talk page for template:Chembox* - thats the reason the edit request is requested here. template:Chembox Formula should be changed as discussed. E.g. [[Chemical formula|Molecular formula]] to [[Chemical formula]] Christian75 (talk) 21:08, 26 March 2015 (UTC)
Objection. Not discussed, not this way. Note to any visiting editor: At this very moment I am working with the sandboxes, and so this request is disruptive. I note that Christian75 already interfered with this process: [10], so Chris75 knows what is going on. (actually, I find this behaviour by this experienced editor beyond the pale. Anyway, this behaviour will not help anything forward). -DePiep (talk) 23:34, 26 March 2015 (UTC)
I really feel you have some kind of ownership over the infoboxes. I suggest changing it, because as you may know, a molecule isnt the same as a salt, and the entry is used for both. Christian75 (talk) 05:36, 27 March 2015 (UTC)
Christian75. We two do have 'battles' about edits, but this 'ownership' thing is more serious. (I'll stay away from the "prove it!" route. Please reconsider your feeling about this).
First of all, I do not claim ownership (but that's my idea ;-) ). In this case, I am actually live editing the {{Chembox}}/sandboxes. I do not claim ownership, but I do claim exclusivity while I'm doing these edits. No serious software editor can edit and test when outside edits are made too (by you or by an admin editor). Full stop.
If you disagree, and you keep the template request up, I'll have to keep this request status controversial.
If you agree and refrain from interfering edits, we can conclude on proposals quity easily here, and then I can build & test all changes. I am very loyal to good talkpage discussion outcomes. -DePiep (talk) 22:32, 29 March 2015 (UTC)
There is no consensus for edits. You're supposed to take he editrequest template down by setting |answered=yes. -DePiep (talk) 17:03, 30 March 2015 (UTC)
I dont know. Earlier in this thread you wrote: "Aha. The label text. Can & will do this next week", but when I tagged it with an edit request then you are takling about no censensus. But it could be nice with some arguments agains it. NaCl isnt a molecule, and therefore it doesnt have a "molecular formula" but a chemical formula. We are using this template for borg salts and molecules (and ions after ionbox was redirected to chembox). Christian75 (talk) 17:22, 30 March 2015 (UTC)
I repeat: No serious software editor can edit and test when outside edits are made too. So if you want edits done, don't mess with it yourself. That is what I call interfering. -DePiep (talk) 17:38, 30 March 2015 (UTC)
I am setting the template to |answered=yes procedurally as it is clear to me that there is not consensus for the change at this time. This is per the template documentation. I have no opinion on the question at hand. --Izno (talk) 18:12, 30 March 2015 (UTC)
I do not know what I should answer to "but I do claim exclusivity while I'm doing these edits. No serious software editor can edit and test when outside edits are made too (by you or by an admin editor). Full stop." You have not edited theese templates for days. Should I say yes to, that I do not edit templates. Christian75 (talk) 00:27, 1 April 2015 (UTC)
Yes Chris. What I'm trying to say is that it's useless to sandbox and test/check edits when others edit at the same time. That's not "owning", that's good editing process. -DePiep (talk) 07:24, 1 April 2015 (UTC)
Exactly, Chris. That is because I am still waiting for you to answer my question: will you refrain from interfering? As long as you keep that possibility open, even by not responding to it, development is in risk of being disrupted. -DePiep (talk) 09:20, 7 April 2015 (UTC)
Done. We're here to build an encyclopaedia; you two's feud has no bearing on this change, and since you both seem to agree on the substance of it, I have now performed it. Alakzi (talk) 22:05, 7 April 2015 (UTC)
Legal status and Pregnancy category: follow Drugbox
Together with |Dependency_liability=, |Addiction_liabiliy= I guess? Unless strong objections appear, I'll set it up like {{Drugbox}}} has. Some months ago there was a nice discussion about the subtleties; cannot find it any more (will search more if you ask). -DePiep (talk) 08:00, 14 April 2015 (UTC)
(appreciated) Will go into this later on. As we both know, it's about the text (including formats & links) of the lefthand-text in the LD50 data row. Not just that link. Later. -DePiep (talk) 19:03, 18 April 2015 (UTC)
Maybe later, but now not, the text should read 'median lethal dose'/'median lethal concentration'. Leaving out the 'median' is, besides confusion, incorrect. --Dirk BeetstraTC04:26, 20 April 2015 (UTC)
You can repeat this over and over, but I still have not seen any arguments from you, except for wikilawyering, why 'Lethal dose' would be correct. On the other hand, there are two people who tell you that it is incorrect and both with reason.
Now regarding BRD, you boldly implemented the term 'Lethal dose' on {{Chembox_LD50}} on February 12, 2015, and afterwards implemented the same on 27 March 2015 on {{Chembox_LC50}} in creating the article (obviously from a copy, you did not update 'lethal dose' there to 'lethal concentration'). In a normal editing process you get then to this version by Christian75, where it says "Median lethal concentration" (You earlier added 'Median', Christian75 changed 'dose' to 'concentration'). You then change that to 'Lethal concentration' (thát is the Bold edit!), get reverted with an explanation (thát is the Revert edit!). And thát is where the Discussion (the last one of BRD) should start. Instead, you undo that edit again, insisting that you do not need to define it. For LD50 the story is similar, you boldly implement a change, there someone else updates that with the explanation that "median lethal dose and lethal dose are not the same", but you revert only because "GF interfering with actual development". As I said above, you have yet to give arguments why 'lethal dose' is correct, why that 'clarifies' what LD50 is. Because the only reason why we should leave you do whatever you want is that otherwise we would be interfering with your programming - an argument that you have used in these edits, an argument that you have repeatedly mentioned here on this page, and elsewhere around on editing these templates, and that starts to show a certain pattern.
So, you reverted twice without talking, even incorrectly claiming BRD while a talk is open. Apart from being incorrect process, it is pedantic to ask for arguments while evading talk yourself. Now I have no reason to trust that you will engage in arguments anyway. -DePiep (talk) 22:17, 3 May 2015 (UTC)
The version I 'enforced' (your words) is this version by Christian75 (diff between that version and now), so yes, that version was published. You Boldly removed, and got Reverted .. that is where the discussion should take place, NOT at your Boldly implemented version, but at the Reverted version. And that while two editors keep telling you that 'Lethal dose' and 'Median lethal dose' are not the same.
But it is now clear you do not have any arguments in favour of this change. Just Wikilawyering, and even incorrect - if you would have given arguments in your reverts, and in this discussion, we would have gone somewhere, but besides the lack of arguments you just imply bad discussion behaviour on your opponents to avoid to have to discuss the arguments. --Dirk BeetstraTC03:29, 4 May 2015 (UTC)
I propose to abandon these three categories (remove from code, so they won't be filled any more; then delete the cat page).
Time ago they could have helped in a sweep task to check and improve, but today that is not at hand. I can give more detailed considerations, if someone asks. -DePiep (talk) 18:32, 18 April 2015 (UTC)
The first and the third can go - the second one is still reasonable, images that are uploaded local (often by a new editor) should be moved to Commons (though I agree that there are other categories that might take care of that) so other wikis can take advantage of them (often chemboxes get copied from other wikis; the image is nice if it then stays the same). I can not really see any reason why there would be non-free material displayed in our chemboxes. --Dirk BeetstraTC05:56, 19 April 2015 (UTC)
All true, but nothing specific for Chembox. We want all images on commons, not local (when they are free). That should be guided by bots and the upload wizard. On a minor note, I see that there is not an eaasy way/template to detect localness, which suggests that indeed in-template detection is not the general route. And if I remember well the Upload wizard has changed since 2010 (start of this cat) to have 1. commons-suggestion and 2. checking for free-ness + to-commons suggestion. -DePiep (talk) 07:37, 19 April 2015 (UTC)
It may not be complete or perfect, still it is best that some of our image-makers withing the chemistry/chemicals-projects go through these (check for correctness and conformity with other images) than a random editor or even a bot. I think, again, that the category is not unreasonable, and if the image maintainers on the chemistry/chemical project use it, it should stay. We should not remove çategories because we don't like them, we should remove them because they are useless. -Dirk BeetstraTC04:35, 20 April 2015 (UTC)
First looks like a reasonable way to catch cases where there is an image available that could be inserted in the box? But that's only useful if there isn't one there already, so for that purpose it's just a subset of the more useful Category:Chembox articles without image. Second is a good list of move-to-commons candidates. @Beetstra: valid reason is if the image is fair-use (Actinium(III) oxide and Promethium(III) oxide). Third looks like a nice cat to keep. There are some reasons to do it (keeping multiple images comparably sized for comparison), but lots look just silly (Chlorofluoromethane) or are possibly used to avoid scaling artifacts (valid heuristic that the image itself is low quality). DMacks (talk) 07:51, 19 April 2015 (UTC)
I have used the second categorie too. Its "easy" to move structural formulas (because of lack of all kind of weird copyrights (e.g. every country in the world has its own copyright for freedom of panorama), and its easy for chemist and to find the correct categorie on commons. Bots do not move images, just suggest they can be moved. Christian75 (talk) 17:12, 19 April 2015 (UTC)
You continue to denigrate/insult these regular and esteemed contributors to the Project. Are you inviting us. M. DePiep, to take you forward for discussion of your behaviour? Excerpting this Talk page alone would likely be enough to get you a cooling off period. Be careful mate. Le Prof Leprof 7272 (talk) 03:45, 1 May 2015 (UTC)
I'm impressed, mostly because you claim to even have read whole threads. But anyway, don't call me "mate", dude. That is a negative to a regular and esteemed contributor. Check your behaviour. -DePiep (talk) 21:59, 2 May 2015 (UTC)
No. 1 can go, no. 2 to remain. I concur with Levo, Beestra, et al. and so there appears to be a consensus on these two of this editor's proposals. Bravo all. For the third, lets see how people respond to @DMacks:. Le Prof Leprof 7272 (talk) 03:45, 1 May 2015 (UTC)
I conclude after reading the arguments & opinions. I'll remove #1 (eponymous) and #3 (img size set). The #1 eponym's do not help any editor, because when searching for a compound's image one wants to have listed all names (including 'stick and ball' names etc). That's what a name search is for. Is in line with the arguments. #3 is less strongly negative in your opinions & args, but I want to throw in some Involved Editors weight. I created this cat a year ago when {{Chembox}} had major changes in image handling. This was a take-a-look category, to be sure that those changes did not corrupt articles. Today this task has been done. The category now does not have an actual maintenance task.
The #2 'local image' I'll leave undecided, as I can not convince people now that this is a wikiwide issue, not chemistry related. So no conclusion in #2, it might reappear later. -DePiep (talk) 22:20, 29 May 2015 (UTC)
It was an erroneous change I made and a reverse request to an admin was made here. I expect that admin to be online soon. -DePiep (talk) 18:13, 16 June 2015 (UTC)
Resolved
Done, see the live demo some lines above. We can tweak. -DePiep (talk) 14:06, 19 February 2015 (UTC)
