Template talk:Infobox isotope

TeX Markup

There is no good reason to resort to TeX markup for the plus-or-minus symbol, so I'm changing <math>\pm</math> into ±.
—Herbee 22:29, 2005 Apr 5 (UTC)

Oh, thanks, I was not aware there was HTML markup for plusminus. oo64eva (AJ) 00:45, Apr 6, 2005 (UTC)

Haha i just realized there is also a plusminus symbol at the bottom of every edit page in the character map... I should pay more attention. ± ± ± oo64eva (AJ) 16:16, Apr 6, 2005 (UTC)

Decay modes

I have made the last three decay modes fully optional (I hope). Rich Farmbrough, 13:06 19 September 2006 (GMT).

Unified for stable isotpes

I chaged the halflife, etc. so that this template would work for stable isotopes. I could have changed that color part can be switched with "stable" or somthing. But I do not know if you would like to do or not.--Shoons 11:31, 19 April 2007 (UTC)

Colours

Hi, I've just improved the template. Please do let me know if there are any bugs!!!

I'm just wondering what rationale you have behind the colours. Should certain isotopes or chemicals be displayed in certain colours? The documentation ought to reflect this. It would make sense to have a colour coding (as they do for animal taxoboxes).

It might be nice, also, to have the option to have a little image to denote stability or decay mechanisms.

Verisimilus T 14:06, 7 May 2007 (UTC)

Magnetic properties etc

How about adding magnetic moment, gyromagnetic ratio, and electric quadrupole moment? Will make a huge difference for us NMR folks. Xenonice (talk) 02:40, 1 May 2009 (UTC)

How do I add decay branch probabilities?

Many isotopes, for example, 238-Pu, can decay in multiple ways. The Infobox isotope has the ability to list four different decay modes and their energies, which is good.

However, we need to list the branch probabilities as well. These are listed in the CRC bible as half-lifes for each decay mode, because often one branch is many orders of magnitude more likely than the other.

To do this, we can define two a new variable for each decay mode, decay_halflife1. I had hoped to modify the template as follows, but it didn't work:

{{!}}-
{{!}} {{{decay_mode1}}}
{{!}} {{{decay_halflife1|}}}
{{!}} {{#if:{{{decay_energy1|}}}|{{{decay_energy1}}} [[MeV]]|}}
{{!}}-|}}
{{#if:{{{decay_mode2|}}}|
{{!}} {{{decay_mode2}}}
{{!}} {{{decay_halflife2|}}}
{{!}} {{#if:{{{decay_energy2|}}}|{{{decay_energy2}}} MeV|}}
{{!}}-|}}

I gave up after I could not even figure out how to make any change at all show up in "Preview". If anyone else can make the template change, I'd appreciate it.

Iain McClatchie (talk) 09:34, 17 September 2010 (UTC)

The change won't show up in preview because no data is specified. To experiment with changes you should copy the template (with your changes) to Template:Infobox isotope/sandbox; you can then use {{infobox isotope/sandbox|test_data=test}} in the WP:SANDBOX to try out different combinations of parameters. Incidentally, I've modified the code you proposed to a more efficient format that will produce the same output.

Missing decay constant - please fix

Would some please add a variable for decay constant, $\lambda$, and I will add it to the radioactive element articles? I hesitate because the template impacts multiple articles, and I'm not sure it's straight-forward to edit. Thank you. --68.107.135.58 (talk) 03:11, 8 May 2012 (UTC)

Just list the half-life (using the variable halflife) instead. The decay constant is just the inverse of the half-life up to a constant factor (see Exponential decay) so it would be redundant to list both. TDL (talk) 00:16, 9 May 2012 (UTC)

If either of the two are included, it should be the decay constant, not the derived half-life. 68.107.135.58 (talk) 16:55, 11 May 2012 (UTC)

Double bold in infofox section headers

A case of having the bold (triple ') and the ! used at the same time in the code. Any objections if I resolve it? GraemeLeggett (talk) 11:34, 23 June 2016 (UTC)

Mass confusion

(with small pun...) I note that there is a source of confusion with this infobox regarding mass. The heading says "Nuclide data" but the box itself has "Isotope mass". Thus, this template on the Deuterium page has the mass that includes the bound electron, that is, it gives the mass of the Dueterium atom, rather than the deuteron nuclide. Seems to me the template ought to perhaps have nuclide mass and also isotope mass. Or something... Bdushaw (talk) 21:13, 17 November 2017 (UTC)

Or there should also be an entry for number of electrons in the Isotope. Bdushaw (talk) 21:15, 17 November 2017 (UTC)

Infobox title typograpy

In the infobox title formatting, I have explicitly added two NBSP spaces. This is for typographical reason (later more) -DePiep (talk) 21:14, 9 October 2019 (UTC)

This is grammatically incorrect and inappropriate. Elements of a list are separated by single spaces, not double spaces. Reverted. Headbomb {t · c · p · b} 21:15, 9 October 2019 (UTC)

(ec) For example, as a title not a sentence, compare (changed to use {{infobox}} more to the point):

Chlorine-37, ³⁷Cl

Label	Data

with

Chlorine-37,  ³⁷Cl

Label	Data

It shows that, with the sequence: -hyphen, nn number, comma, space, superscript, symbol letters a separation between the two main elements (English naming and international code), the title is more clear. -DePiep (talk) 21:27, 9 October 2019 (UTC)

There is already a grammatically valid separation, for lists, a comma followed by a single space. It is just as clear, and has the considerable benefit of being correct. Headbomb {t · c · p · b} 21:30, 9 October 2019 (UTC)

re "gramatically incorrect": it is about whitespace, which has nothing to do with grammar. Whitespace is used to improve typography, the esthetics & pleasantness of texts and reading. There is no rule that says this is not "correct". And again, this is a title, not a "list". -DePiep (talk) 10:27, 10 October 2019 (UTC)

That is a non-argument. That's like saying that "it's not a list, therefore we can separate two elements of the title with an obelus "Hydrogen-3 ÷ ³H". Titles follow grammatical rules, like anything else, and here the title is formed by the joining of two elements in list form. When commas are used as a separators, they are followed by single spaces, not double spaces. Headbomb {t · c · p · b} 11:23, 11 October 2019 (UTC)

Editwarring. You know I object. You have not gained consensus (actually, you did not even start a talk), so no base for the change. -DePiep (talk) 11:46, 11 October 2019 (UTC)

I didn't start a talk because you did, and I invited WP:ELEMENTS to comment. And the base for change is proper grammar. Headbomb {t · c · p · b} 12:58, 11 October 2019 (UTC)

I’d normally oppose two spaces after a comma. In this case, where each title would include two identical numbers, one normal case and one superscripted, I agree two spaces makes the title somewhat easier to grasp. Sandbh (talk) 22:50, 11 October 2019 (UTC)

I agree. With the single spacer, there is not enough separation for me to readily identify that there are two different elements in the title. I expect this problem would be even greater in an infobox which uses a smaller font size. I note that a comma is sometimes used (with no spacing) inside a chemical formula. Although the given use would never be ambiguous, nevertheless, I think it might be wise to eliminate a comma entirely. I actually like the separation with the obelus better than either but I recognize that this would probably not fly.

There are other options. One could write Chlorine-37 (³⁷Cl) ^{now that I've clicked "Show preview", I see that doesn't really work well}. With the right markup, one could left justify the Chlorine-37 and right justify the ³⁷Cl. But between the two listed alternatives, I much prefer the one with two spaces. YBG (talk) 02:11, 12 October 2019 (UTC)

Actually, now that I've looked closer, I do not like the obelus. I carelessnessly thought that the glyph being displayed was a swing dash (⁓). Both of these are nonstarters. Sorry for adding confusion. YBG (talk) 05:16, 12 October 2019 (UTC)

I could live with (³⁷Cl), but the double space is simply incorrect. Headbomb {t · c · p · b} 22:50, 12 October 2019 (UTC)

re YBG: no reason to use brackets, (a nice excercise it is). Because: both title elements are defining the isotope (or element in the other infobox), no need to indicate a subordination. Even better: the symbol one is more international.

Anyway, as Sandbh writes: with more whitespace (say doublespace), the names and symbols are easier to grasp. That is, because the eye can more easily distinguish theem. It is not a sentence. -DePiep (talk) 23:21, 15 October 2019 (UTC)

Any thoughts to expanding the whitespace to the max by left justifying one and right justifying the other? Also to be considered, perhaps reversing the order might provide some benefit. YBG (talk) 23:23, 15 October 2019 (UTC)

Thought of those, but to me doesn't seem to give improvement. Natural reading & understanding order (here) is: name, → symbol. Using outer limits looks awkward, and actually breaks the reasing. Tbh, I don't se a need for any change (away from double space). -DePiep (talk) 06:10, 16 October 2019 (UTC)

Re order, I understand and agree. Re max spacing, its advantage over double-space is that it makes it absolutely clear that it isn't a sentence and further it eliminates the need for a coma, which I think is a bit unsightly. But if it weren't for trying to achieve a broader consensus, I wouldn't press the issue. Max spacing is my first choice, but the double-spacing alternative is a close second. YBG (talk) 06:53, 16 October 2019 (UTC)

• The world uses whitespace (not just single fixed width space) everywhere. Also vertically. In general: none! of these whitespacings are the same.

For example

In numbers

123456.7, 11100

In tabular lists

• foo
• foo
• foobar

Horizontal lists ({{hlist}})

• foo
• foo
• foobar

In indenting (using ::)

Foo

Bar

Foobar

In textual paragraphs

Blabla par 1.

Foofoo par 2.

Bulleted list

• 1-Some thing
• Some other thing
• The rest

Numbered list

1. One
2. Two
3. Three

Table

(e.g., wikitable)

Etcetera.

Technically they can be thinspace, figure space, ... too. While indenting whitespace can be anything the typographer prefers. So: various whitesapace is a common typographical form, also outside of sentences. -DePiep (talk) 23:43, 18 October 2019 (UTC)

Irrelevant, none of those are phrases. In lists, commas are followed by single spaces. This is not a matter of preference, but a matter of proper grammar. Headbomb {t · c · p · b} 00:07, 19 October 2019 (UTC)

none of those are phrases—exactly, nor is the title of an infobox. "Grammar" is irrelevant: this is a title, not a sentence nor a phrase. The examples show: various lists can have various whitespace, also vertically. They can have, and they do. (i.e., whitespace is not a grammatical rule but a typographical choice—all over wikipedia. -DePiep (talk) 00:18, 19 October 2019 (UTC)

Clearly you don't know what a phrase is: "A phrase is a group (or pairing) of words in English". But regardless of it being a phrase or not, it is still a list, and in comma-delimited lists, commas are followed by single spaces. Headbomb {t · c · p · b} 00:54, 19 October 2019 (UTC)

(Easy reply: "And you don't know what a title is".) But seriously: grammar-does-not-prescribe-size-of-whitespace. -DePiep (talk) 01:07, 19 October 2019 (UTC)

Grammar does dictate how many spaces follows a comma. And the answer is one. Headbomb {t · c · p · b} 01:13, 19 October 2019 (UTC)

1. Your link is not a Wikipedia policy/MOS so it cannot "dictate",

2. It says (that is: your argument itself says) in Rule 1: "The space needed after these punctuation marks is proportioned automatically" (my stress). In typography (that is: not grammar), the amount of whitespace is quite variable: see this #Overview; (BTW and these are only the predefines characters; a typgraphy dsigner is even more free to adjust whitspace),

3. While it says "use only one space following periods, commas", this is not correct e.g. in "100,000", nor for lists that apply newlines e.g., here,

4. Here, the infobox correctly creates a nerwline after the comma in "Post-transition metal,<newline>alternatively considered ..."

5. Again, please stop applying running sentence guidelines to titles.

-DePiep (talk) 16:53, 20 October 2019 (UTC)

100,000 isn't a list. Headbomb {t · c · p · b} 22:41, 20 October 2019 (UTC)

Whitespace varies in situations. Glad you could not counter my main point :-) -DePiep (talk) 22:46, 20 October 2019 (UTC)

And in lists, the whitespace is a single space, not a double one. Headbomb {t · c · p · b} 22:59, 20 October 2019 (UTC)

Back from start? Above I showed four lists, none of these having "single space" separation. (tabluar lists, unbulleted list, hlist, bulleted list, numbered list, paragraphs). --DePiep (talk) 06:37, 25 October 2019 (UTC)

• I agree with the objections. Stuffing an extra space (or any other content) in there is simply wrong; it's a classic failure of separation of content and presentation, of the kind widely excoriated since the obsolescence of HTML 3 in 1997 (and criticized in smaller circles for decades). On the Web, if you need to visually kern something for readability then do it with a tiny bit of CSS spacing. A convenient way to do this inline is (using an exaggeratedly spaced example): like <span style="display: inline-block; margin-left: 3em;">this</span>, which renders as: like this. (The inline-block is needed, because such spacing does not normally apply to a span or other inline element.)  — AReaderOutThataway ^t/_c 10:31, 22 October 2019 (UTC)

@AReaderOutThataway: Let me check if I understand your point. Do you mean to say, that setting whitespace by css is OK, just don't use space characters ("content") for it? If so, that would make it OK to change the amount of whitespace in this by using css. (While the objections are, in my words: amount of whitespace is not to be chosen). IOW, you suggest a technically different solution per good design, but you do not object to the intent. -DePiep (talk) 08:28, 24 October 2019 (UTC)

Exactly. I don't have a strong opinion on the design intent, though generally have no issue with kerning for readability (and under other ID have created other templates that do that for some special cases).  — AReaderOutThataway ^t/_c 03:28, 25 October 2019 (UTC)

Since the discussion has stalled, and lack of sensible objections, I've restored the semantically correct single-spaced version. Headbomb {t · c · p · b} 12:11, 24 November 2019 (UTC)

I disagree with your assertion of a lack of sensible objections. Here are quotes from the other four participants in this discussion:

• DePiep Whitespace is used to improve typography, the esthetics & pleasantness of texts and reading
• Sandbh I’d normally oppose two spaces after a comma. In this case, where each title would include two identical numbers, one normal case and one superscripted, I agree two spaces makes the title somewhat easier to grasp.
• YBG With the single spacer, there is not enough separation for me to readily identify that there are two different elements in the title Max spacing is my first choice, but the double-spacing alternative is a close second.
• AReaderOutThataway Objects to violating separation of content and presentation, but says generally have no issue with kerning for readability

Three of these clearly believe that additional whitespace is helpful in this situation; the fourth does not object to changing the kerning but objects to doing it with hard-coded spaces as opposed using a technique that separates content and presentation.

I believe that the consensus here is that additional spacing is needed; the question is, how much. My suggestion of maximal spacing may be too much, but as only one editor reacted to this, I'm not prepared to say there is a consensus to remove that idea from consideration.

Comments? YBG (talk) 04:39, 25 November 2019 (UTC)

@Headbomb:: Apologies, I failed to ensure that you were pinged in the above. YBG (talk) 04:42, 25 November 2019 (UTC)

If you want to change spacing for whatever reason, the way to do that is not through double spaces, which are semantically wrong and grammatically incorrect. Headbomb {t · c · p · b} 04:45, 25 November 2019 (UTC)

@Headbomb:: So if I understand it correctly, your position is akin to AReaderOutThataway, you have no objection to additional space, but you strongly object to adding it with hardcoded &nbsp;&nbsp;. Is that correct? YBG (talk) 04:54, 25 November 2019 (UTC)

Amongst other reasons. I fail to see why there is a need for more space there to begin with, and not   randomly   between    words. But if additional spacing was created via semantically valid ways, I would have much less of a problem with it. There's also Chlorine-37 (³⁷Cl) as an alternative if people can't live with a single space. Headbomb {t · c · p · b} 05:10, 25 November 2019 (UTC)

@Headbomb: I suggested using parens, but as soon as I hit Publish changes and saw the result, I thought it looked ugly, primarily due to the superscript immediately after the opening paren. What would you say are semantically valid ways to create additional space? YBG (talk) 05:18, 25 November 2019 (UTC)

Tritium

Tritium is listed twice in the Name, symbol line in the infobox. Also, maybe the label should say name(s)? YBG (talk) 15:56, 20 October 2019 (UTC)

Done/fixed. Names, always plural b/c next to "iodium-123", "I-123" is a name too not a symbol. -DePiep (talk) 16:33, 20 October 2019 (UTC)

Thanks!

btw, I'm not sure that there's a clear distinction between name and symbol. YBG (talk) 22:00, 20 October 2019 (UTC)

Neither am I. For this, and to keep the infobox as clear as possible, I take: 1. Symbol = ¹²³I (International, unambiguous, variants excluded). 2. Names' TX ÷ are like Iodium-123 (English only), I-123 (derived, OK in context, but not consistent eg in chem formulae). Simplifies singular/plural too. 3. Elsewhere, like in medicines, isotopes are even 'named' (identified) like "(123I)" ouch, see Iofetamine (123I) (fine with me, when in context. But problematic when automating & parsiing a drug INN, eg {{Infobox drug}}).

Glad we have one well-defined chemical symbol. -DePiep (talk) 22:12, 20 October 2019 (UTC)

How about changing the label to one of these

• Synonyms
• Names

or, if we remove the symbol from the value:

• Names for <symbol>
• Synonyms for <symbol >

YBG (talk) 22:53, 20 October 2019 (UTC)

a name is a synonym. The international chem symbol is great, and serves all. What is wrong with current form? -DePiep (talk) 23:02, 20 October 2019 (UTC)

Nothing wrong just trying to improve.YBG (talk) 05:24, 21 October 2019 (UTC)

Specific activity

Would it be possible to add an extra field to the template Infobox isotope to easily provide the numerical value of its specific activity at least in Bq/g (or a multiple value, such as MBq/g, GBq/g, TBq/g...), and possibly also in μCi/g. Naturally, it only makes sense for radio-isotopes or radionuclides. For instance: 166 TBq/g for ²¹⁰
Po. In advance, thank you very much. Shinkolobwe (talk) 01:33, 20 December 2023 (UTC)