Talk:Table of nuclides/archive (complete)

This was the talk page for Isotope table (complete), which is now Table of nuclides (complete).

There is also an Isotope table (divided) with its own talk page that you may want to look at.

For instructions on using templates in the isotope table, see Template talk:Iso1.

File size and background colours

This is one of the largest pages i Wikipedia. I have therefore tried to reduce its size on the danish copy. In IE 6 it looks OK, but it might not in others. If you use another browser, try and have a look.Jan Pedersen 12:55 23 Jul 2003 (UTC)

Something's broken. I'm using Mozilla 1.4, and on the Danish table I don't see the "foreground" colours for the isotopes with alternate decay paths. Something to do with div tags, perhaps? Bryan

Found the problem. Your're not putting double quotes around attribute values; I belive the standard requires them. So <div style=background-color: yellow;> needs to be changed to <div style="background-color: yellow;">, for example. Tried that with one and it looks like that fixed it. Bryan

Thanx Bryan. I have substituted all "<div style=background-color" with "<td bgcolor". It is now even smaller than before. Would you take another look using Mozilla? Jan Pedersen 08:19 24 Jul 2003 (UTC)

That's no good, you're throwing away information. The whole point of the div tags is to give a cell of the table two colours, one of them the background colour (the <td background= colour) and one of them the foreground colour (the <div style= colour). This is because some isotopes have multiple different decay mechanisms, which have different half-lives. I'd suggest just putting the quotes in; scrimping a few bytes here and there is not worth making the table less useful, IMO. Bryan

Thanx again Bryan. Now I see what you mean, now I don't ;-). When using the "Cologne blue" skin as I usually do, the standard stylesheet is not used. I therefore never saw the effect indicating the isotopes with meta states. Do you think the missig stylesheet should be reported as a bug?Jan Pedersen 09:05 25 Jul 2003 (UTC)

Direction of axes

Conventionally, the axes are defined the other way round, so that isotopes of an element exist in a horizontal line. Would it be not to tricky to write a little script which reorders the table? Pstevenson 17:22, 28 Feb 2004 (UTC)

Wikilinks to element articles

I was trying to link to all the istoscopes from the chart not finshed someone else please help put [[ ]] around element abbreviations -David

Table markup

This is a very neat table. In Firefox, the bottom left gridlines are still visible, though. There is probably a way to make them invisible on all browsers. - Omegatron 19:24, Jun 23, 2005 (UTC)

I fixed this a while ago. — Omegatron 19:52, 7 January 2006 (UTC)

They're still visible in Firefox for me, too. I'm adding a more direct approach that works for me, defining the border for each of those cells to be of 0 width. Bryan 20:18, 7 January 2006 (UTC)

Templates make editing easier and file size is halved

Originally the Nynorsk copy of this article was more than 90 kB, which caused a lot of trouble. The most noticeable was that software introduced errors during edit/save, e.g. the isotope ⁷⁵Ge (in code: <small><sup>75</sup></small>Ge) was changed to <small>Ge (in code: <small&gt;<sup&gt;75&lt;/sup></small>Ge), and another place the attribute bgcolor="#993399" was changed to bgcolor="#993399" resulting in a black cell.

In order to reduce the file size and avoid such errors, and also to make editing of the table easier, I introduced a couple of templates to take care of all the colours and <small>'s and <sup>'s. The file size was reduced to less than 45 kB (*) and editing is a lot easier now. There is one template for one-coloured cells (~2000) and one for two-coloured cells (~200), with simplified syntax for white cells or white borders. The two-colour template could do everything but uses more text to do it, and is only used for the two-coloured cells. The templates are described in more detail at the article's talk page. The template code is in English so I believe most of it is understandable, although the talk page is in Norwegian. --Eddi (Talk) 00:48, 26 July 2005 (UTC) / --Eddi (Talk) 12:38, 27 July 2005 (UTC)

(*) For comparison the Danish copy discussed above is 63 kB.

Looks like the way to go to me. Couldn't the leading cell separator pipes on each line also become part of the templates? ...Huh. Here I am, thinking I was the only one with those odd escaped character insertions. Do you know more about this bug, whether it's on the Wiki software side or specific to certain browsers (like Opera 7.54), or even how to avoid it? Femto 11:22, 26 July 2005 (UTC)

The cell separators could have been in the templates but were left out to maintain a kind of uniformity in the table coding. Since it would only free about 2 kB out of 43 anyway, I think it's OK. Theoretically it allows for extra attributes such as font effects in individual table cells, which wouldn't work if the separators were in the templates, although I see no current need for such attributes. The same templates may also be used rather neatly in other contexts, e.g. the half-life colour chart on top of the article, like this:

{| align=right cellpadding=2 cellspacing=0 border=1 |+ '''[[Half-life|Half-lives]]''' (example: [[Gadolinium|Gd]]) |- | {{Iso1|145|Gd|-}} || Unstable |- | {{Iso1|146|Gd|V}} || 1-10 [[day]]s |- | {{Iso1|149|Gd|I}} || 10-100 days |- | {{Iso1|153|Gd|B}} || 100 days - 10 [[year]]s |- | {{Iso1|148|Gd|G}} || 10-10,000 years |- | {{Iso1|150|Gd|Y}} || >10,000 years |- | {{Iso1|152|Gd|O}} || Natural [[radioactive]] |- | {{Iso1|158|Gd|R}} || Stable |}

Half-lives (example: Gd) 145Gd Unstable 146Gd 1-10 days 149Gd 10-100 days 153Gd 100 days - 10 years 148Gd 10-10,000 years 150Gd >10,000 years 152Gd Natural radioactive 158Gd Stable

Regarding escaped characters I don't really know what causes the errors, but I use Opera, too. I try to avoid errors by always previewing my edits and sorting out obvious flaws, then searching for any additonal &lt;'s, &gt;'s, &quot;'s, &amp;'s etc. (or just &'s or ;'s) that may have been introduced while pressing 'Preview', and in the end I just cross my fingers while pressing 'Save'... Not very scientific, that is. --Eddi (Talk) 12:38, 27 July 2005 (UTC)

After some testing, Opera seems to be the culprit. I've got a large HTML file here with a textarea that demonstrably doesn't contain any odd characters. Loaded into Opera, there's an escaped &amp;. Don't tell now, you've also got a sporadic error with empty edit areas that don't show any content, right? Femto 17:40, 27 July 2005 (UTC)

On top of my head I don't remember, but that doesn't mean it never happened. I only remember major trouble with one other page, namely a language politics discussion that ended up over 180 kB. While it was still "only" 133, most of it was duplicated by someone and it grew larger than 250 kB before I fixed it with great difficulties. What caused the duplication I don't know, but my trouble fixing it may have been Opera related. --Eddi (Talk) 22:58, 27 July 2005 (UTC)

Introducing templates to en:Isotope table (complete)?

Would it be a good idea to introduce similar templates in the English copy? It would involve 2 main templates (Iso1 and Iso2) plus 8 colour templates (e.g. Iso/R containing the string ff9999). If such templates should be used here, would it be easier to transform it locally or translate the Nynorsk copy? The English copy contains a whole bunch of recently discovered unstable isotopes of both light and heavy weight that are not (yet) included in the Nynorsk copy. --Eddi (Talk) 22:58, 27 July 2005 (UTC)

I thought that's what this is all about in the first place. Converting the more recent content will be better of course. User:Femto/templatedisotopetabledraft Apart from the colors and a few red links, as a preview at the Nynorsk Wiki using their templates, it appears identical to the English version here. You may want to give it a more thorough check though. Femto 12:05, 29 July 2005 (UTC)

To be honest I was afraid of the transformation task, but now that you've done it I fear nothing. :) I copied Template:Iso1 and Template:Iso2 from nn: and the draft table appears nice and orderly. I'll add the colours and the proofreading may commence. --Eddi (Talk) 13:12, 29 July 2005 (UTC)

I have now proofread the draft table with respect to colours, and all the coloured cells have correct backgrounds and borders. I have not checked to see if all white cells are included, or if all links to special isotopes are in place. To check this I would like to overwrite the existing table with the templated one, and then look at the history diff to spot any missing cells or links. Would that be all right? --Eddi (Talk) 12:56, 4 August 2005 (UTC)

Alternatively you could just preview the diff with the show changes button, but diffs are easily thrown off sync with data like this. Another approach would be to load both pages into separate browser tabs, scroll them to similar positions, and then flip back and forth between the pages (number keys 1 and 2 with Opera). Differences in the visual appearance of the pages will stand out as 'jumps' in the image. Femto 15:23, 4 August 2005 (UTC)

I'll use the show changes button, which I think is safer than flipping tabs. --Eddi (Talk) 18:51, 4 August 2005 (UTC)

Following a complete proofreading of the draft vs. the live table, I have implemented the templates in the live table. As far as I can see, all isotopes are included, all colours are the same as before, and all links are in place. --Eddi (Talk) 19:55, 4 August 2005 (UTC)

PS: To support the diff sync I kept the spaces in the "! NN" lines (where NN is the neutron number) so that those lines were unchanged. --Eddi (Talk) 23:42, 4 August 2005 (UTC)

If/when the templates are introduced in the live table, there must be an instruction for the use of the templates. I can copy the essentials from :nn. Should the instruction be in Template talk:Iso1 / Template talk:Iso2 or a section of Talk:Isotope table (complete)? (By the way, I think there should also be a more detailed explanation of the various border colours. This could be placed together with the template instructions.) --Eddi (Talk) 12:56, 4 August 2005 (UTC)

Detailed instructions should go with the talk page of the first template, and a reference to that at the top of talk:isotope table (or any other page which uses them). Femto 15:23, 4 August 2005 (UTC)

I have written instructions at Template talk:Iso1. A reference is inserted on top of this page. --Eddi (Talk) 18:51, 4 August 2005 (UTC)

I noticed that the draft table has "shadow" cell borders, that is, grey to the left/upside and white to the right/bottom. I think this may obscure the rightfully white borders of isotopes with multiple decay pathways. Could we keep the simple, grey cell borders of the current table? --Eddi (Talk) 12:56, 4 August 2005 (UTC)

This apparently also depends on the browser. Which part of the code could cause it? Both versions render the same on my system, as shadows, I never saw gray borders. Femto 15:23, 4 August 2005 (UTC)

No idea what causes it. Different name spaces? Just now I'm borrowing a computer with only Internet Exploder. --Eddi (Talk) 18:51, 4 August 2005 (UTC)

Introducing templates to en:Isotope table (divided)?

Now that the templates have gone live in the complete table, how about the divided table? (As you might expect, I'm all in favour.) Should the existing divided table be transformed, or should the already transformed complete table be divided? --Eddi (Talk) 23:42, 4 August 2005 (UTC)

Something of both. It will make the least work to keep the formatting stuff from the divided table, scan for the number-and-symbol entries, replace them with the corresponding lines from the complete table, and there you go. User:Femto/templatedisotopetabledraft2 Found no obvious flaws in the coding. Besides proofreading this single page, it would also be a good time to check for differences and synchronize the data between (complete) and (divided). Femto 16:19, 5 August 2005 (UTC)

I'll have a look at the proofreading one of these days. As to synchronisation I believe the major differences lie with Dubnium (changing Ha to Db) and Bohrium (changing Ns to Bh). --Eddi (Talk) 22:14, 10 August 2005 (UTC)

Another point in favor of using templates is that they make automatic comparisons easier due to the standardized coding. Excluding Db and Bh, the following entry lines are mutually missing in either table: Ne-15, Mg-31, Mg-33, Al-21, Si-22, Si-23, Si-24, P-24, P-25, P-26, P-45, P-46, S-41, S-42, S-43, S-44, S-45, Cl-44, Cl-45, Cl-46, Ar-47, V-45, Mn-48, Co-51, Co-52, Cu-55, Cu-56, Cu-57, Zn-58, Zn-59, Ga-59, Ga-60, Ga-61, Ga-62. Note that this only checks for exact same occurrence and doesn't catch things like slipped rows or changed content, so a manual check is still advisable. Femto 10:29, 12 August 2005 (UTC)

I've compared the templated version vs. the old version of the divided table with respect to cell colours and wikilinks, and found 2 differences; F-18 is linked vs. not linked, and Si-32 is blue vs. green. The F-18 link is OK as far as I'm concerned, but I suppose this can wait until the synchronisation between complete and divided tables. The half-life of Si-32 according to the silicon article is 132 years, or 160 years according to WebElements, which in the isotope table corresponds to green (10-10000 years). I'll make changes in the draft for F-18 and Si-32, plus Db and Bh. --Eddi (Talk) 13:54, 17 August 2005 (UTC)

In general I haven't looked at white cells yet, but this could also be part of the synchronisation. I suggest we make a note at Talk:Isotope table (divided), then intoduce the templates in one edit without any other changes (apart from Db and Bh), and in a separate edit synchronise the complete and divided tables. --Eddi (Talk) 13:54, 17 August 2005 (UTC)

Made a note at Talk:Isotope table (divided) 18 August, and introduced the templates to Isotope table (divided) 22 August. See that talk page for details. Now everything should be set for #Synchronisation of complete and divided tables. --Eddi (Talk) 22:59, 22 August 2005 (UTC)

Linking the talk pages of the complete and divided tables

Some of Talk:Isotope table (divided) is also valid for the complete table, and vice versa. I suppose a redirect may be too drastic, but there could at least be a prominently displayed link between the talk pages. --Eddi (Talk) 22:14, 10 August 2005 (UTC)

Yes, these pages should be linked together much more prominently, like a reference at the top of the talk, and/or as part of the template comments in the article code. Many editors may introduce changes to one page without even realizing there's another version. We may also designate one page (preferably the 'complete' one) as mother and one as daughter for a more defined flow of information. Femto 10:30, 12 August 2005 (UTC)

I have now inserted red boxes on top of each talk page with links in both directions. I didn't designate any of them as parent or child, but that may be done with little extra effort. --Eddi (Talk) 20:59, 18 August 2005 (UTC)

Featured list candidate

Oh, this is lovely! When you are done, please come to WP:FLC to nominate it as a Featured list. -- ALoan (Talk) 12:58, 19 August 2005 (UTC)

OK. --Eddi (Talk) 23:44, 19 August 2005 (UTC)

Issues to be addressed before nomination

If the isotope table is going to be nominated as a featured list candidate, I think a few issues should be addressed to meet the FLC criteria on usefulness, comprehensiveness, and accuracy (I believe the other criteria are already met):

• Critical view on user friendliness with respect to layout, colours, ease of navigation, links to other articles, etc.
• Verification of isotope data.
• Section on references: Isotope table (complete)#References.
• Review of the term "stable": What constitutes a "stable" isotope?
• Review of the term "natural radioactive": Does it imply a certain half-life, does it amount to a certain percentage of the natural abundance, or is it some other quality unrelated to half-life and abundance?

A formal project may not be required, but a group of editors should be ready and prepared to handle any shortcomings of the article during the nomination period. I'll set up a list of interested editors below – feel free to add your name. --Eddi (Talk) 20:52, 4 September 2005 (UTC)

References

Just got confirmation from Bryan that the now defunct http://www2.bnl.gov/CoN/nuchart1.html (BNL), which was the source for this data, indeed is the same site as the archive.org'ed [1]. (You might have to turn on javascript, play around with the link, and/or replace the date string with an asterisk to get that silly thing to work.) Their reference was given as

R.R.Kinsey, et al.,The NUDAT/PCNUDAT Program for Nuclear Data,paper submitted to the 9 th International Symposium of Capture-Gamma_raySpectroscopy and Related Topics, Budapest, Hungary, Octover 1996.Data extracted from NUDAT database (Dec.18, 1997).

Femto 11:42, 10 September 2005 (UTC)

I cannot understand why International Atomic Energy Agency gets credit for Interactive Table of Nuclides? Interactive Table of Nuclides (http://www.nndc.bnl.gov/nudat2) is developed and maintained by the National Nuclear Data Center (NNDC) at Brookhaven National Laboratory. International Atomic Energy Agency is only hosting it, providing the second installation in addition to NNDC.

"Stable" and "Natural radioactive"

So whichever is the exact meaning of "stable" or "natural radioactive", our definitions are BNL's definitions. Apparently, http://atom.kaeri.re.kr/ is the direct successor of that page, maybe there's also something buried in their FAQ. In the long run, and before a featured nomination, I agree though that it's absolutely essential for these articles to set their own definitions. There does seem to be no Wikipedia-wide agreement on those terms, let alone on the web. Femto 11:42, 10 September 2005 (UTC)

For example, we could look for ideas in the border styles and definitions used in the periodic table. The categories there are stable, natural, artificial, and unknown. The definitions of stable and natural seem to be different than in the isotope table – and they cover elements, not individual isotopes – but they're worth looking at and perhaps harmonising in the long run. --Eddi (Talk) 00:10, 11 September 2005 (UTC)

According to [2], ¹¹³Cd has half-life of 9.3x10¹⁵ years and abundance 12% in natural cadmium, which would seem to fit in "natural radioactive", but it is colored yellow for >10000 years. (the center, not the green border which is ^113mCd) --01:39, 12 April 2007 (UTC)JWB

Editors interested in helping the article to featuredness

• Eddi (Talk) 20:52, 4 September 2005 (UTC)

Commit myself? I'm crazy, but I'm not that crazy. :p Femto 11:42, 10 September 2005 (UTC)

After modifying the section header, I take your comments as interested anyway. :-) --Eddi (Talk) 00:10, 11 September 2005 (UTC)

Colour intensity in table cells

Inspired by the Danish version of the isotope table, lighter colours were introduced in the Norwegian version by simple manipulation of the 8 colour templates. The contrast between cell text and background colours improved very much, not only for blue and red wikilinked text but also for normal black text. Compare the English version with any of those or, for an instant comparison, see the half-life colour chart in the Norwegian test version. Various colours have been discussed for various purposes at the isotope project and the deep colours were apparently chosen for the isotope table at some point, but I gather nothing is set in stone. Are there any objections to lighter colours here, perhaps except that it shouldn't be done before the templates have been implemented in the divided table? --Eddi (Talk) 23:44, 19 August 2005 (UTC)

Synchronisation of complete and divided tables

As mentioned by Femto above, some isotopes were missing in either the complete table or the divided table. I have now added or corrected the following entries in each table:

• Isotope table (complete): Ne-15, Al-21, Si-22, Si-23, Si-24, P-24, P-25, P-26, P-45, P-46.
• Isotope table (divided): Mg-33 (was Mg-31), S-41, S-42, S-43, S-44, S-45, Cl-44, Cl-45, Cl-46, Ar-47, V-45, Mn-48, Co-51, Co-52, Cu-55, Cu-56, Cu-57, Zn-58, Zn-59, Ga-59, Ga-60, Ga-61, Ga-62.

--Eddi (Talk) 03:17, 4 September 2005 (UTC)

Alternatives for displaying colour legend

Can we somehow make the colour chart float over the article so that it's still visible when scrolling down and right through the isotope table? --Eddi (Talk) 12:38, 27 July 2005 (UTC)

I'm not an expert about the Wiki software but I believe it doesn't support anything remotely like putting pages (or parts thereof) into frames. Such a navigation bar would have been nice though. Femto 17:40, 27 July 2005 (UTC)

One could wish, yes. If I'm really in the mood one day I might just post a bug. Or persuade somebody else... :) --Eddi (Talk) 22:58, 27 July 2005 (UTC)

That is a CSS issue, not need to mess with wiki software or frames. Just add 'position:fixed' to the style. Works in any decent browser. See demo--Joris Gillis 15:49, 7 January 2006 (UTC)

I stand corrected on the technical matter. However, the floating box obscures Wikipedia's own navbar, edit fields, or footer for example. It still seems rather kludgy, and Wiki's pages should be technically as simple as possible unless there's no impact on the accessibility for the majority of readers. If it would be possible to keep the box within the context of the Wikipage and have its own scrollbars, then perhaps. Though re:"works in any decent browser", the first Google hit I get for "position:fixed" is a hackaround on how to get it working in Internet Explorer without too much fuss. (I'll let everybody decipher their own meaning from that... :) Femto 19:18, 7 January 2006 (UTC)

Maybe it's better to provide a tooltip for each cell.--Joris Gillis 10:01, 8 January 2006 (UTC)

Thank you for contributing to the the isotope templates and isotope tables. However, I have been unable to open the isotope tables after you changed the templates. Introducing complex recursive templates used thousands of times in an article may be extremely hard on the servers. Could you please go back and revert your changes? If you want to experiment, you may consider using template copies, not live templates, and keeping the experiments out of the main article space. For example, I believe User:Femto/templatedisotopetabledraft and User:Femto/templatedisotopetabledraft2 have served their purpose and are free game. And talk pages such as this one and Template talk:Iso1 are always useful for discussing major changes. Thank you. --Eddi (Talk) 18:36, 9 January 2006 (UTC)

Half-lives (example: Gd)

145Gd	< 1 day
149Gd	1–10 days
146Gd	10–100 days
153Gd	100 days–10 a
148Gd	10–10,000 a
150Gd	10 ka–700 Ma
152Gd	> 700 Ma
158Gd	Stable

The reason for the slow response had indeed to do with the changes I made in the templates. I tried to introduce logic, but the server couldn't handle it. What shall I do?--Joris Gillis 20:08, 9 January 2006 (UTC)

I just found a solution. Version 1.6 of the MediaWiki-software introduced defaulting for parameters. The overhead is now virtually none: no need for nesting/logic--Joris Gillis 09:01, 10 January 2006 (UTC)

Great! With the title property we don't have to consult the colour chart all the time. I'll update the template instructions as necessary. --Eddi (Talk) 15:55, 10 January 2006 (UTC)

Glad you like it:-) But how about the double case? (Iso2) what should the title say? --Joris Gillis 16:27, 10 January 2006 (UTC)

With respect to popup-titles, the two-coloured cells are a challenge, yes. There are 8x7=56 different text combinations if the frame and the centre can have any colours, or 7+6+5+4+3+2+1=28 combinations if the centre colour is always more "stable" than the frame colour (*). If we must use 28 or 56 new text files I think we should forget about it, but if it can be done with some template magic the titles could for example be as in the table below. --Eddi (Talk) 22:38, 11 January 2006 (UTC)

(*) There are a lot of isomers that are more stable than the ground state, you'll probably need most of those combinations. Femto 12:09, 12 January 2006 (UTC)

Cell	Code	Title	Code of title part of cell
93Nb	{{iso2|93|Nb|R|G}}	Half-life – Isotope: Stable; Nuclear isomer: 10–10,000 years	Half-life – Isotope: {{iso/R/text}}; Nuclear isomer: {{iso/G/text}}
91Nb	{{iso2|91|Nb|Y|I}}	Half-life – Isotope: 10k–103M years; Nuclear isomer: 10–100 days	Half-life – Isotope: {{iso/Y/text}}; Nuclear isomer: {{iso/I/text}}
89Zr	{{iso2|89|Zr|V|-}}	Half-life – Isotope: 1–10 days; Nuclear isomer: < 1 day	Half-life – Isotope: {{iso/V/text}}; Nuclear isomer: {{iso/-/text}}

I have made an {{iso-test}} template, currently with the same syntax as for {{iso2}}, and put it to the test in the table above. It allows any values of parameters 3 and 4 within R/O/Y/G/B/I/V/-/blank. With this template introducing isomers in the popup titles, there is even more reason than with the current iso2 template to stress that it should only be used if two colours are actually needed, although it is able to present one colour correctly and could in theory be used for all cells. --Eddi (Talk) 15:40, 12 January 2006 (UTC)

The two-fold titles are now implemented in the {{iso2}} template. The titles had to be moved from the overall cell code to the inner div code to make them visible on the text, so the "title area" (the area where the mouse cursor triggers a title) is smaller than with {{iso1}}. A worse problem, however, is that the title is not visible on the "<sup>" mass number with either template – and the title area is almost non-existent in cells with wikilinks. Any suggestions? It could be improved if the wikilinks were on the numbers (alternative 2) instead of the text (alternative 1): --Eddi (Talk) 10:05, 5 February 2006 (UTC)

Alternative 1	2D	4Li	5He	12C	13N	131I	235U
Alternative 2	2D	4Li	5He	12C	13N	131I	235U

Alternative 2 above is now used in the isotope table (complete) for the isotopes of H, He, Li, C, N, I and U that link to separate isotope articles. Compare with alternative 1, which is still used in the isotope table (divided). --Eddi (Talk) 22:18, 10 April 2006 (UTC)

Tantalum 180 nuclear isomer stability

The two-coloured cell for Ta 180 indicates that there is a nuclear isomer that is unstable (the white border). However, elsewhere on Wikipedia (under "nuclear isomer") we are told that Ta 180 has the only stable nuclear isomer.

One of these must be wrong - I suspect the first, since elsewhere there is reference to Ta 180 isomer stability - see [3].

I'm not sure if I can edit this, perhaps someone can have a go?

Edit - had a go now - looks ok

Isotopes of tantalum gives a halflife of >1.2E+15 a. The reference you linked uses the word "stable", but then gives "a half-life of > 10¹⁵ years". Nuclear isomer says only "nearly-stable" and "half-life is at least 10¹⁵ years". This puts it in the extremely long lived category, so I'm going to change it back.

Should blanks under elements 16-25 be fixed?

i fixed the one under He (moved column down), but others exist and should be filled in. e.g. 28S has a pretty long half life.. Eupedia 05:58, 5 April 2006 (UTC)

I originally added those blanks for aesthetic reasons, to reduce the jaggedness of the headers and provide a bit of separation for some of them to make them stand out more. Aesthetic judgements are quite disputable, of course, just pointing out a possible reason for leaving things as they are (which is always the easier option :). Bryan 06:49, 5 April 2006 (UTC)

For what it's worth, here's another opinion that it looks better when label-cells and content-cells won't touch. Femto 12:24, 5 April 2006 (UTC)

Second that. I don't mind if the labels touch the contents here and there, but in general the table appears better with smooth edges above and below the jagged cells. Actually this should be used more, not less, especially at the lower edge. (I'm not volunteering though. ;) --Eddi (Talk) 01:25, 6 April 2006 (UTC)

i love Bryan Derksen's solution/edit: fill in the blank with something interesting (diproton)! thanks, Bryan. 24.5.187.236 05:57, 6 April 2006 (UTC)

decay modes, products, half-lives, etc.

Half-lives (example: Gd)

145Gd	< 1 day
149Gd	1–10 days
146Gd	10–100 days
153Gd	100 days–10 a
148Gd	10–10,000 a
150Gd	10 ka–700 Ma
152Gd	> 700 Ma
158Gd	Stable

is there another version of this on the wiki that shows richer data for each isotope? plans for one? here's an idea: alternate text that would give the richer data upon mouseover somehow. not sure how to implement, tho. 24.5.187.236 06:02, 6 April 2006 (UTC)

It is partly included in this version, although not very detailed. Try to hover over the coloured cells to the right. So it is possible. But it would be a lot of work to add all the extra details, and I think there is a risk that the data would not be proofread as thoroughly or updated as frequently as it should be, because the data would not be immediately visible on the page. --Eddi (Talk) 17:37, 6 April 2006 (UTC)

Another possibility might be to say "screw size! People can scroll, or get 40" monitors, damnit!" and create another version of this page where each cell actually includes a bit of text with the information. :) Bryan 17:44, 6 April 2006 (UTC)

:D That's definitely an option. It's still a lot of work, but at least transparent and therefore safer with respect to reviewing and updating. But does the wiki software cope with file size? The current file is close to 50 kB. How big would the new file be, assuming that templates could still be used to reduce repetitive formatting? --Eddi (Talk) 18:39, 6 April 2006 (UTC)

Wikisource uses the same software (Mediawiki), and its largest page right now is just shy of two megabytes in size: [4]. My biggest concern for this sort of thing is editability, though; IE used to not be able to handle articles over 32 kilobytes in a text box, and the nature of a table such as this would prevent the use of headers to break it up into smaller chunks. When I try editing the article in Firefox 1.5 I get the following message: "ERROR: The text you have submitted is 1,948 kilobytes long, which is longer than the maximum of 1024 kilobytes. It cannot be saved." Don't know what the limits of other browsers is. Bryan 00:59, 7 April 2006 (UTC)

Actually, now that I check in more detail, it seems Firefox is handling it and it's MediaWiki that's telling me "no." So I guess one megabyte is the limit on Wikisource. don't know what the limit for Wikipedia is, perhaps it's configrable. Bryan 01:02, 7 April 2006 (UTC)

And compulsive tidier that I am, I've gone and ruined my example by splitting it into four subpages. Ah well. [5] still has the two megabyte version in its history. :) Bryan 01:18, 7 April 2006 (UTC)

what about the free neutron (element 0)?

Most charts that I have seen include the free neutron (p=0, n=1), as a natural extension of the table next to deuterium. The free neutron article even includes a mini-isotope-table picture (shown at right) with the free neutron included in the table. The neutron undergoes beta decay, just like many other nuclides, and has a known half-life (which according to the article is 15 minutes), so I think it should be included in the isotope table. Spoon! 02:54, 28 June 2006 (UTC)

Yeah, I agree. It would make sense to me given the free neutron article. Peter 04:24, 20 February 2007 (UTC)

Helium-2?

This chart shows an isotope Helium-2, yet that is not listed in Isotopes of helium. Which is correct? Should Helium-2 be added to Isotopes of Helium, or should it be removed from here? Nik42 01:03, 15 September 2006 (UTC)

The helium-2 entry links to diproton, and isotopes of helium has a seealso to it, I think that's fine. We need to be consistent though. Should or should not this chart include things like neutron, diproton, triproton, etc. ? Femto 11:18, 15 September 2006 (UTC)

I'd be OK with adding the neutron, because it is common practice. I would not add the diproton because as far as I know it doesn't exist. Tables of isotopes usually include only the isotopes that have been observed experimentaly. Itub 23:35, 27 September 2006 (UTC)

"Natural radioactive"; neutrons

It has already been discussed above: The term "natural radioactive" is unclear. I think the corresponding entries should be divided up into the other categories. The source from which the data had been taken in the first place soon after changed their own data so that "natural radioactive" was no longer present. However, I don't have a problem with "stable". It says: "This nuclide is belived to be (absolutely) stable."/"No decay has been observed." Also, I agree with Spoon! that the neutron should be added. Quilbert 18:34, 26 January 2007 (UTC)

Most of the "natural radioactive" cells would fit in a "very long halflife" category with a threshold of, say 500 million years to include ²³⁵U. Also, a reasonable meaning of "natural radioactive" would be isotopes that have survived on the Earth during its lifetime. I agree that listing the few shortlived members in this category is misleading and that they should be classified according to their halflife:

3T 12.32a

10Be 1.51E+6a

14C 5.70E+3a

215At .10ms

231Pa 3.27E+4 a

234Pa 6.70h

234U 2.455E+5a

--JWB 06:06, 20 April 2007 (UTC)

Isotopes that have survived since the beginning of Earth are also sometimes called "primordial" (there's some debate about whether primordial plutonium-244 has been detected...). --Itub 07:24, 20 April 2007 (UTC)

Should we change the key to say "primordial" instead of "natural radioactive" then? I think only Template:Iso/O/text and Template:Iso1 have to change. --JWB 01:05, 25 May 2007 (UTC)

I added the states of free neutrons, but didn't remove diproton because it had an article. Syphon8 05:28, 16 November 2007 (UTC)

204Pb

Lead-204 is marked as having an isomer of >10000 years, but Isotopes of lead does not seem to list it. Does anyone know where this came from? --JWB 08:21, 20 April 2007 (UTC)

Red to gray?

How do you feel about using gray for stable isotopes?

• It seems logical (red can suggest activity or heat) and less distracting.
• Believe it or not, there is a policy WP:BETTER#Use colour sparingly saying Colour should only be used sparingly... Specifically, use the colour red only for alerts and warnings. I don't think this needs to be applied rigidly to an isotope table, but it does agree with the previous point.
• Wikipedia:WikiProject Isotopes#Color scheme already uses gray for stable.
• It would be very easy to implement (just in Template:Iso1 I think), unlike other color changes like implementing all of Wikipedia:WikiProject Isotopes#Color scheme or even subdividing the existing categories.
• It would free up red for reuse if we do want to do something like subdividing an existing category. Splitting either of the existing yellow (range of 10⁵) or green (range of 10³) categories would take 26 changes or less. --JWB 01:29, 25 May 2007 (UTC)

I'm going to give gray (BBB) a try as nobody has objected so far. Discuss here or at Template talk:Iso1. --JWB 19:05, 28 June 2007 (UTC)

Now that gray represents the most stable isotopes, I think we should also reverse the order of colors for the rest of the stability range so that darker, cooler colors (gray, purple, blue) represent more stable isotopes, and lighter, warmer colors (orange, yellow, white) represent less stable isotopes. --IanOsgood (talk) 19:53, 25 November 2007 (UTC)

In one way that's intuitive, but on the other hand it's reversed for glowing hot bodies, which start at red hot and move towards blue with increasing temperature, although the middle of this temperature spectrum is white instead of green. See Color temperature and Black body#Explanation. --JWB (talk) 20:16, 25 November 2007 (UTC)

Sure. However, humans have a different perception of color warmth. See Color symbolism and psychology and search for "warm". A lightness gradient from dark gray to white also makes the table look better on the typical white page background. --IanOsgood 17:11, 3 December 2007 (UTC)

Any color comes in lighter or darker versions. Or are you proposing using grays only? --JWB (talk) 17:45, 18 December 2007 (UTC)

Stable and long-lived (>700 Myr) isotopes

I fixed the colors of long-lived and stable isotopes as them are known today. Namely, the following changes were made:

• 48-Ca, 76-Ge, 82-Se, 96-Zr, 100-Mo, 116-Cd, 128-Te, 130-Te, 130-Ba, 144-Nd, and 150-Nd are not stable, them are double beta (2b) active;
• 151-Eu and 180-W are alpha active;
• 123-Te, 142-Ce, 156-Dy, 149-Sm, 192-Os, and 204-Pb are not radioactive (claims on registration of radioactivity were later carefully checked and "closed", as, for example, for 123-Te). For their half lives, only lower limits are known. So them should be considered as stable.
• 180-Ta ground state is short-lived (8.125 h) and its excited state is (meta)stable with only lower limit on the half-live known (>1e15 yr).

Let me give a list of 31 nuclides that are known to be radioactive with half-life >7E8 yr (i.e. primordial radioactive nuclides) as for today (decay modes: alpha (a), beta (b), double beta (2b), spontaneous fusion (SF), cluster emission(CE)):
40-K (b), 48-Ca (2b), 50-V (b), 76-Ge (2b), 82-Se (2b), 87-Rb (b), 96-Zr (2b), 100-Mo (2b), 113-Cd (b), 116-Cd (2b), 115-In (b), 128-Te (2b), 130-Te (2b), 130-Ba (2b), 138-La (b), 144-Nd (a), 150-Nd (2b), 147-Sm (a), 148-Sm (a), 151-Eu (a), 152-Gd (a), 176-Lu (b), 174-Hf (a), 180-W (a), 187-Re (b), 186-Os (a), 190-Pt (a), 209-Bi (a), 232-Th (a, SF), 235-U (a, CE), 238-U (a, 2b, SF). V1adis1av 14:40, 25 August 2007 (UTC)

Thanks for the corrections. It looks like a lot of the neutron-rich isotopes undergo double beta decay.

I would also like to note that there are no halflives between 103my (¹⁴⁶Sm) and 704my (²³⁵U) --JWB 15:14, 25 August 2007 (UTC)

Yes, one can check it here [6] . Between half-lives of 146-Sm and 235-U there are nothing. --V1adis1av 15:53, 25 August 2007 (UTC)

Bi²⁰⁹

This footnote, from Kilogram explains something clear enough:

---

In 2003…physicists found that the only naturally occurring isotope of bismuth, ²⁰⁹Bi, is actually very slightly radioactive, with the longest ever radioactive half-life of any naturally occurring element that decays via alpha radiation—a half-life of 19 ±2 × 10¹⁸ years. As this is 1.4 billion times the age of the universe, ²⁰⁹Bi is considered a stable isotope in virtually all practical applications.

---

Accordingly, I changed the color coding for ²⁰⁹Bi to “stable” (grey) but added a hidden editors note explaining the rationale for labeling it as so. Greg L (my talk) 06:57, 3 February 2008 (UTC)

Merge?

I don’t see any reason (even file-size-related ones) as to why Isotope table (divided) and this article can’t be merged into one featuring both styles of table. Why do the two styles have to be on separate pages so that two articles have to be maintained?

I don’t believe a case can be made now that two articles are necessary due to file-size issues. I see from this post: Templates make editing easier and file size is halved, that problems seemed to occur only when files grew to the 63–180 kB size range. That was back in 2005 though. Since then, templates have reduced this article to only 48 kB and the other is only 50 kB. And, of course, browsers have been updated since then to handle more complicated Web pages (and larger ones too, presumably). Isn’t it time to try a merged version? I suspect it would be under 100 kB and I’m sure modern browsers can handle that; after all, United States is 161 kB.

Maintaining two articles that are supposed to have identical content is not the way to do things on Wikipedia.

Having said all that, my highest complements to all who’ve worked on his—especially Eddi. Making templates takes a lot of time and his donation of all his time had to have been a real labor of love. This article is extremely useful and is an awesome resource. It would sure be nice though, to not have two of them to maintain. Greg L (my talk) 18:33, 3 February 2008 (UTC)

• P.S. Seeing no response after two weeks (were there no responses because my above suggestion was borne out of ignorance(?) or just because there was a lack of interest?), I implemented a trial merged version. As you can see, it is extremely easy to navigate because the added sections also added a table of contents. If this merged version doesn’t work, it is only too easy to undo. As the size of the merged version is 102,855 bytes (100.44 kB), I believe it should offer bug-free performance with modern browsers; after all, the United States article is 161 kB.

  I think the virtues of this unitized method are many: There is now a handy pictorial representation of the periodic table immediately below the TOC so users can quickly look up exactly which sub-section to click on. Further, links to this article from elswewhere on Wikipedia can now take a reader directly to an element of interest while still giving the reader freedom to scroll the entire contents of what used to be two entirely separate (but totally redundant) articles. Greg L (my talk) 22:41, 17 February 2008 (UTC)

Sorry I missed your earlier query. I think this is a bad idea that if anything is negative for usability. It's precisely because the content is redundant that there is little reason for a reader to need both copies in one scroll. The whole idea of the divided table is to reduce the need for horizontal scrolling in the first place. If we are going to have an even bigger area to scroll through, that frustrates the original intent and we might as well get rid of the divided table.

Putting them on one page does nothing to make maintenance easier. You still have to maintain two copies of each entry, but have to do even more scrolling. If you could find a way to generate both formats from a single list that would not need double maintenance, then that might be useful.

50k is about the limit where splitting is suggested, plus this page is one of the slowest to load anyway, presumably because of the template evaluation. One reason I have spent a good deal of effort getting rid of empty cells is to reduce size and load/display time. Also, server load will be approximately doubled by putting both tables on one page. --JWB (talk) 02:07, 18 February 2008 (UTC)

• No scrolling whatsoever is required when one choses to use the segmented tables; that’s what the TOC and the pictorial period chart provides the reader. The reader gets the best of both worlds with this approach—whichever one the reader chooses. There are a number of usability enhancements with this new layout, including the placement of individual color legends precisely where they’re needed instead of once at the top of the entire article. Speed seems to be pretty decent—at least on my machine—with a load time of 6.55 seconds the first time (after a history flush) and 3.80 to re-visit. And my machine is far from “fast” as it’s a modest iMac G4 chugging along at 1.25 GHz and is running an older version of Safari.

  I am truly astonished that the articles could be maintained and synchronized as well as they have been thus far. The whole notion of having two, independent discussion forums(!) to debate content issues in two articles that are supposed to stay in perfect synch—while novel—is nearly beyond belief. Greg L (my talk) 02:54, 18 February 2008 (UTC)

File size

I was expecting the periodic table image to be an image map that would take you straight to a particular element, but looks like it's just a picture.
→That’s a natural reaction and I doubt you’ll be the last to do it (once). I did my best with the caption: Use this pictorial periodic chart as a guide in selecting the desired table from Contents below. Still, it’s quite handy. One can be directed to this article from, for instance, the Kilogram article where they were reading up on Bismuth. A handy periodic chart helps to figure out which isotope group to click on in the TOC. Greg L (my talk) 07:44, 18 February 2008 (UTC)

Looks like you placed the color key on each segment of the divided table. That's good, but could have been done as easily without combining the two pages, and does nothing for the single table. Not sure what other usability enhancements you are talking about.

I have always used the single table. It is harder to trace decay chains and trends across the divided table boundaries. The divided table segments are also smaller than they could be.

Render speed for the page seems fast, but when I edited the page, preview took 27 sec. I've experienced much slower before, so the server/load ratio must be better than at those times.
→I agree; slow for editors. Sweet for readers as they now “have it all” in one convenient place. Greg L (my talk) 07:44, 18 February 2008 (UTC)

Right, but having two redundant tables on one page is still no benefit to the reader, who wants to consult one or the other at a time. Moving between the two tables was hardly inconvenient as they were prominently linked from each other. --JWB (talk) 17:58, 18 February 2008 (UTC)

There are more then two discussion forums - a lot of the discussion also happened at Template_talk:Iso1 and probably elsewhere. It's all too common and hard to avoid for discussion of a topic to spread over multiple articles, templates, etc. Eliminating just one page is not going to eliminate the problem. You still have to monitor and post on multiple pages. For the issue of updating specific entries in the table, it seems to have been handled by editors updating both, or at least posting in Talk saying what they did in one. But, as noted, two independent entries for each isotope still have to be kept in sync, it's just that they are on one large page. --JWB (talk) 06:52, 18 February 2008 (UTC)

Also, have you noticed how many versions of the Periodic table exist and are separate articles? --JWB (talk) 18:16, 18 February 2008 (UTC)

Also note when you edit this article or the divided table and preview, you get a warning message "This page is 101 kilobytes long.", or 53 for the divided table page. This is to tell you that the page is getting longer than recommended by policy. --JWB (talk) 18:11, 18 February 2008 (UTC)

Please see Wikipedia:Article_size#A rule of thumb. --JWB (talk) 18:26, 18 February 2008 (UTC)

• JWB: I’ve long needed and enjoyed both styles of table. Sometimes, I like to scroll through the unitized version and watch patterns develop. Other times, I want to go straight to a particular element and just look at its column so I use the segmented versions. I browse and explore and find it enormously easy and convenient to do so with this now-integrated version. I know I’m not unusual in this regard.

  Let’s also be fair while referencing Wikipedia advise on file size. The very article you referenced above stated here that “With some web browsers with certain plug-ins running in certain environments, articles over 400K may not render properly…” and went on to discuss browser limitations. The “100 kB” recommended size is borne out of desire to ensure that regular prose-based articles don’t suffer from bloat-itis and become boring. Notwithstanding this policy, there are still 28 Wikipedia articles that exceed 200 kB, and one, (link to article) that is 430 kB! Anyway, non-prose reference tables are immune to this “boredom-based” file-size concern; they are almost entirely reference data. The beauty of Wikipedia is we can use the power of web browsers to make it extraordinarily easy to find what one is looking for and we have extraordinary flexibility in presenting the data to the reader. The past performance problems with these isotope tables seem to have been fixed—largely due to efforts of people like Eddie, who made the extraordinarily efficient templates they rely upon.

  Now that this article has enhanced usability features like the ← Previous |  Next → navigation links, color-code legends in each section, and the periodic table visual reference guide, this integrated version is, IMO, far more convenient than the separate versions ever were as stand-alones; the whole is greater than the sum of the parts. Absent any compelling performance problems (which I doubt will crop up due to modern browsers and Eddie’s work), it no longer makes sense to split up two views of identical content.

  I think we’ve both conveyed our positions quite well here and suggest that we sit back and see how others feel about this. Clearly, there are going to be those who are disappointed with the change, want things back to the old ways, and will quickly find their way here to weigh-in. But hopefully, some users who visit this article and like it, will see fit to come to this discussion page and post a quick note regarding their impressions. To other authors and readers: please weigh in regarding performance issues. Notwithstanding that this article “previews” rather slowly while editing, does it suffer from performance issues when it loads while browsing? Greg L (my talk) 20:47, 18 February 2008 (UTC)

Greg: Nobody is against the links and keys you've added to the divided table, but these are independent of the issue of merging the two articles. I also have no problem with inclusion of the periodic table image, although in the case of the divided table, you could actually add links to it.

I'm aware of the template work from 2005 and have done work on them myself and have considered further changes. I've also considered adding additional isotope tables in other useful formats, such as turned 45 degrees so that isotopes with equal numbers of protons and neutrons form a vertical line, or with the most stable nuclide of a given mass number at the vertical center line - a prototype of the latter is in my private pages. I plan to add these eventually after further work. Again, please consider the example of the many formats of periodic tables.

WP:Article size documents known problems at 400k as you noted, but this is not the same as its recommendations for article size which are much smaller. WP:Article size#Occasional exceptions says:

Two exceptions are lists, and articles summarizing certain fields. These act as summaries and starting points for a field and in the case of some broad subjects or lists either do not have a natural division point or work better as a single article. In such cases, the article should nonetheless be kept short where possible.

In this case, of course the new page made of two articles put together, has an obvious division point. We disagree on whether they "work better as a single article" - I think you have still not come up with any specific benefits to readers from the merge, but just keep repeating that it is a good idea in general without any more detailed justification, and point to other enhancements that are separate from the merge. The policy concludes "the article should nonetheless be kept short where possible", and clearly merging the two pages is not this. --JWB (talk) 21:14, 18 February 2008 (UTC)

• We can’t hijack file-size policies—like “100 kB”, which applies to ordinary prose-based articles—and pretend they apply to this case. This is a unique situation because this article simply presents two views of the exact same data. The policy on file size is intended for articles like Mass versus weight, which used to be a section within Kilogram. It was split off from Kilogram and made into its own article, where it can be separately discussed and dealt with. Independently maintaining absolutely identical isotope data in two separate articles, each with its own separate discussion venue(!?!) makes absolutely no sense. Experts on isotopes who aren’t as proficient as you and I at editing Wikipedia often won’t even know to go hunt down the other article and make the exact same edits there.

  I don’t pretend to speak for everyone else on Wikipedia and I hope you aren’t either. It seems the two articles have diverged into separate camps with their own turf when the original reason for bifurcating it in the first place—performance issues—no longer exists. The only real measures of whether this article is now better is to see how well received it is by the larger community and whether some users experience performance issues. It’s time now to take a deep breath and let others express their opinion too, JWB. My bet is that others will like this newly integrated multi-view with its “ ← Previous |  Next → ” nav tools and other enhancements. I might be wrong; we’ll see. Greg L (my talk) 00:46, 19 February 2008 (UTC)

Greg, now you're repeating yourself. I will try to restrain myself from repeating in my answer, and trust that readers have read the responses above.

I've merged your nav and key enhancements (a total of 8 source lines) into Isotope table (divided), so they are not an issue in the question of whether to merge the two pages. None of the enhancements were to the unified table. Please stop citing them as an advantage of merging the two pages. I will say, after actually using them, that the Previous/Next links you provide are substitutes for scrolling the short distance to the previous or next section (which may actually be easier for the user than moving the mouse pointer to the Previous/Next links if the pointer is not close to them already) and do nothing about the much more substantial problem of moving a longer distance within the article. If I were adding nav links, I would give each section of the divided table a line of links to every other section of the divided table, which would be far more useful, and still take only one line.

When I actually have wanted to compare the unitary and divided isotope tables, I have used two tabs or windows side by side, allowing comparison of the corresponding sections. Scrolling halfway through the single article to compare corresponding sections of the unitary and divided tables would be much harder.

We are not hijacking policies for prose articles - WP:Article size does in fact have a specific section for lists/tables, which is the WP:Article size#Occasional exceptions I quoted above that you seem to not have understood.

Please note the Synchronisation of complete and divided tables and other sections of this and the other talk page, as well as the crosslinks at the top of the page, which editors maintaining this page successfully used to manage the double updating problem. If you really find the existence of two talk pages to be intolerable, one can be redirected to the other to provide a single page. The past editors did not find this to be necessary, but it is certainly easier and less crowded than forcing both actual tables to live on a single huge page.

Besides the additional isotope tables of different formats I am planning to add, isotope data also occurs and is maintained at many other places, such as the articles on each element and the "Isotopes of <element>" articles. Ideally all of these would be automatically generated from a single data table. If you can help figure out a way to do that, that would be useful. Simply merging two of the pages without even eliminating the problem of double maintenance of each isotope entry within the merged page, is no help at all. --JWB (talk) 01:25, 19 February 2008 (UTC)

• Already done (regarding additional nav links). You certainly seem as if you don’t like the idea of letting others weigh in on the matter. Greg L (my talk) 01:32, 19 February 2008 (UTC)

Greg, please see WP:Merge#How to merge pages. If there is any controversy, you must seek consensus on the merge, before executing or reexecuting it. Listing the page on WP:Proposed mergers is also helpful for getting feedback. --JWB (talk) 02:12, 19 February 2008 (UTC)

As for the nav links, no, I meant links to each section of the divided table, not just to the top of the unitary table (which is near the top of the page anyway). I've implemented a simple example at Isotope table (divided). --JWB (talk) 02:16, 19 February 2008 (UTC)

• I’ve added more nav links so readers can instantly snap back to the periodic table and to the unitized table. I’m flattered you liked the navigation features and the repeating color legends and incorporated these concepts into Isotope table (divided). But now that performance issues are no longer a problem, independently maintaining absolutely identical isotope data in two separate articles, each with its own separate discussion venues(!?!) makes absolutely no sense. You certainly seem as if you don’t like the idea of letting others weigh in on the matter. I felt that since all the information was here—and in a damn-handy format too—that it was fair and proper to post the merge tag to alert other editors that it was no longer necessary to synchronize two separate articles. Go ahead and delete the merge tag if you want. I’m not trying to kill off an article that seems to be dear to your heart; I’m trying to make this one ridiculously convenient. Greg L (my talk) 02:25, 19 February 2008 (UTC)

  P.S. I withdrew the merge tag myself. I wasn’t trying to piss in someone’s cornflakes; I thought that since all the damned info had been copied over, it was the proper thing to do. Fighting this has been most un-fun and I can think of better things to do. Greg L (my talk) 02:34, 19 February 2008 (UTC)

Merge? Fresh effort

JWB: A “consensus” isn’t required for an editor to edit or expand this article. A wider consensus is only required if Isotope table (divided) is to be merged (deleted) in the process. It is wholly inappropriate and in exceedingly bad form for you to copy and mimic the enhancement and features I’ve implemented here and then simply delete all my work before other editors have had a chance to evaluate its merits and voice their opinion. Here’s what “divided” looked like before I started my work over here, and here’s what it looked like after you copied many of my improvements and then deleted my improvements from here. When done the way you just did it, it’s no longer “copying” and is just simple “stealing.” What an astonishingly large degree of gall that took. It’s also a metric ton of weapons-grade bullonium and I’ll have none of it. Such behavior is simply not tolerated on Wikipedia and there are remedies such as Wikiquette alerts if you continue to operate this way.

In your edit summary where you deleted all my work, you wrote “Moved back to Isotope table (divided), if merge is approved by consensus, can move back here.” There was no “move” from “divided” to here, “divided” was left completely alone. If there was a “move” of any sort, it was when you copied all my ideas and hard work and then deleted them all here; now that’s a “move.” You need to be honest with your edits and your edit summaries and your discussions. If your position is that Wikipedia is better off by continuing to have the articles separate, then you must let others weigh in on the matter instead of taking upon yourself to delete the tables I added.

After several days of your furious typing here about integrating these two articles, you have been the only one who has objected to the integrated approach. No one is even afforded an opportunity to look at the possible advantages when you just delete it all. Having a single article to maintain makes just too much sense sense and I can’t help it if this possibly-better way of doing it threatens your desire to retain Isotope table (divided); it’s time to let others voice their opinion on the matter. Your arguments about file size issues are a red herring and have nothing to do with the matter; download speed is plenty fast.

My position is simple: Independently maintaining absolutely identical isotope data in two separate articles, each with its own separate discussion venue(!?!) makes absolutely no sense. Experts on isotopes who aren’t as proficient as you and I at editing Wikipedia often won’t even know to go hunt down the other article and make the exact same edits there. The “100 kB” recommended size you’ve referred to was borne out of desire to ensure that regular prose-based articles don’t suffer from bloat-itis and become boring. Notwithstanding this policy, there are still 28 Wikipedia articles that exceed 200 kB, and one, (link to article) that is 430 kB! Non-prose reference tables are immune to this “boredom-based” file-size concern; they are almost entirely reference data. The beauty of Wikipedia is we can use the power of web browsers to make it extraordinarily easy to find what one is looking for and we have extraordinary flexibility in presenting the data to the reader. The past performance problems with these isotope tables seem to have been fixed—largely due to efforts of people like Eddie, who made the extraordinarily efficient templates they rely upon.

I think other editors and users will find that my proposed method is a convenient-to-use and attractive way of doing things but they have to be able to see and try the proposed new way (which you’ve copied the crap out of) in order to be able to offer an opinion! Still, all your copying doesn’t put both types of table in one convenient place nor does it solve the enormous problem of trying to keep two articles in perfect synch.

Let me make myself perfectly clear: In your attempt to avoid a consensus for merging by desperately improving “divided” you are not permitted to “copy” every single one of my handy usability and navigation features from here, duplicate them over on “divided” and then completely delete every single spec of my work here. That is a simple breathtaking display of theft. You may “borrow” and “copy” my usability ideas here to make “divided” look better (something you’ve shown great facility at)—Wikipedia and all its readers are the beneficiaries when you do so. Both articles may be improved and from hereon, others get an opportunity to evaluate its merits now. Decisions will be made by “consensus.” If there is to be a consensus, it will be by many others weighing in as to whether or not this integrated approach is better. If there is to be a consensus, it will be whether or not to “merge” (delete) Isotope table (divided). Your behavior here is beginning to look like an ownership issue and you’ve taken it entirely upon yourself to decide what will be permitted. As you’ve no-doubt seen by now, I’ve put the proposed “merge” tag back into “divided” so others can come here and be able to make an informed decision on the matter. Wikipedia is a “collaborative” writing environment; get with the game plan. Greg L (my talk) 16:15, 19 February 2008 (UTC)

Now you are getting really, really silly.

You moved content from Isotope table (divided) to Isotope table (complete) and proposed to delete the first. This is a merge, though you originally misrepresented it by adding a quick delete tag instead of a merge tag. Consensus is required before performing the merge. It is you who have failed to let others weigh in, and are continuing to do so. You may repropose the merge if you have changed your mind again since yesterday, and given the disagreement, this time should better inform other editors of the proposal via WP:Proposed mergers, WP:WikiProject Isotopes, WP:WikiProject Elements, etc. If consensus is obtained for the merge, *then* you may perform it, copying the content and converting the copied page to a redirect. Until then, the content of Isotope table (divided) remains at that page, and not the page you propose to merge it to. If you feel the need to provide a view of what the merged page would look like, normal procedure is to create your proposed work as a subpage below your user page, and provide a link to it in the Talk discussion of the merge.

I reversed the premature merge, after you withdrew the proposal and removed the merge tag, and carefully preserved your non-merge-related work from the prematurely merged text, so you could not complain about deletion of that. If, improbably, you don't want your work preserved, just revert Isotope table (divided) back to the previous version. You need to understand WP:OWN as well as observing WP:Good faith, WP:GAME, and the more specific policies and processes.--JWB (talk) 20:32, 19 February 2008 (UTC)

• My withdrawing the proposed merge was intended as a show of good faith because you were coming across as nearly in a panic over the prospect of merging “divided”—what with all your near-instantaneous “copying” of my usability features. It was not an invitation to undo everything I did over here. Just let others evaluate this way of doing things on Isotope table (complete) so they have an opportunity to add their 2¢ here. So far, you’ve been the only one objecting to the merge. Greg L (my talk) 22:10, 19 February 2008 (UTC)

It sounds like you are interpreting "merge" to mean only getting rid of one article. That is deletion, not merging. Merging means combining the content. If there is controversy, you wait for consensus before doing it. Withdrawing the merge means you are not combining the content and leaving the articles separate.

I've explained why I think merging is a bad idea. I think editors knowledgeable in the subject will agree with me, but if consensus is for merging, that's fine. HOWEVER, you do not proceed with the merge before then. It's plainly said in WP:Merge#How to merge pages: if the merge is controversial, or if someone reverts it (which I did, after you said you abandoned it, though in hindsight I should have done it immediately), you must propose and get consensus before proceeding with it. Until then, leave the divided table in its own article. --JWB (talk) 00:07, 20 February 2008 (UTC)

To be even more explicit, you should put your proposed merged version at User:Greg L/Isotope table to allow editors evaluating the merge proposal to see it, and not place merged versions at Isotope table. I'll leave it up to you whether the nav links (which are pretty simple compared to Wikipedia standard navbars) and extra instances of the color chart are in Isotope table (divided) or not; I ported them there to separate them from the merge issue and as a courtesy to you when undoing the abandoned merge you hadn't yet bothered to clean up. --JWB (talk) 00:10, 20 February 2008 (UTC)

I'm the one who originally created both of these pages, and there actually is a very important usability reason for having both "complete" and "divided" versions. The "complete" version requires two-dimensional scrolling in order to follow the stable elements down the center. Having a really long page is not a big hassle for web browsing, and is very common; there are many easy ways to scroll up and down a page and people are quite used to it. Scrolling side to side, on the other hand, is much less widely supported and isn't as intuitive. It also may play havoc with some skins and layouts (haven't checked this out in detail). On the other hand, having a complete version all in one table is quite handy and more informative than the broken-up version. So both versions have value that the other is missing, and so IMO deleting one or the other will decrease the total value Wikipedia is providing. Not a good option. If the complaint is simply one of difficulty of maintenance, perhaps we could use templates for the contents so that each set of tables is actually generated by the same "source". I suspect that'll make editing the table much harder for new editors, though, since it'll be harder to find the right bit. Bryan Derksen (talk) 01:55, 20 February 2008 (UTC)

• Bryan, though there might not be an “official” policy on it, being the one to have created both articles in the first place (thank you very much) gives you an important voice in this matter and should be heard and understood. So I’m now confused when wrote of the inconvenience of having to scroll in the “complete” version. My sense is that the issue of convenience is extremely well addressed now by simply clicking on the Segmented table option from the TOC and navigating from there. Is it not? Have you tried it? It seems that the “complete” version as now revised—if one chooses to use just the individual tables—is now far more convenient than “divided” was only three days ago. What am I missing here? Greg L (my talk) 04:22, 20 February 2008 (UTC)

That's simply concatenating the "divided" article onto the end of the "complete" article. I have no problem with this in principle, but it doubles the size of the page and it doesn't affect the issue of maintainability one way or the other. I'm not sure how this can be seen as a solution to objections about the current structure. Bryan Derksen (talk) 04:49, 20 February 2008 (UTC)

Vote regarding isotope table (complete/divided)

Please add solutions to the list below if you feel that none of the proposed solutions so far are ideal. The proposed solutions are:-

1. Delete isotope table (complete), leaving just isotope table (divided), and rename to "Isotope table".
   1. Votes:
      1. I vote for keeping the "divided" (i.e. broken down into segments) format. --Rebroad (talk) 01:28, 20 February 2008 (UTC)
2. Delete isotope table (divided), leaving just isotope table (complete), and rename to "Isotope table".
   1. Votes:
3. Keep both articles but perform a “soft merge”: The data for both pages is stored in a template. See User:Quilbert/Experiment for how it could be done. See also User:Quilbert/Table of nuclides.
   1. Votes:
      1. Bryan Derksen (talk) 04:40, 20 February 2008 (UTC)
4. Add “divided“ features to “complete” to have both ways in one place, and add features to make it easier to jump straight to and within the “divided“ portion (this much has already been done.) And also… Merge “divided” into “complete” and then move “complete” to a new article named “Isotope table”.
   1. Votes:
5. Create a new article that would appear similar to Quilbert’s User:Quilbert/Experiment as well as the current Isotope table (complete). As such, both views of data (unitized and segmented) are simultaneously available in one place and the quick-jump nav aids are retained. The display-article’s code is distinct from (and smaller than) the sole database template to which it refers. Both existing articles (“complete” and “divided”) would be deleted. The existing articles, “complete” and “divided”, would be first merged and then moved to a single article embodying these features (in accordance with Bryan Derksen’s 02:49, 21 February 2008 (UTC) post, below).
   1. Votes:
      1. • Strong support I changed my vote. I think this approach adopts the best features of all the available options and support it as my primary vote (in preference over option #4, above, which is where I had been heading). With Quilbert’s idea, there is only one database to maintain; only one edit must ever be made to affect a change.

           Download times with this option wouldn’t be any different from what we currently see with this article because the actual HTML download-code (551,702 bytes) wouldn’t change; what has to be slapped up on the screen doesn’t change even though things are done differently behind-the-scenes. However, that amount of download code is comparable to the very frequently visited United States article, which has an HTML download size of 536,156 bytes. In order to better calibrate our mental “sizeometers,” in should be further noted that 2007 Texas Longhorn football team is a 598,925-byte HTML download and Area codes in Germany is 686,475 bytes. We should keep our eyes peeled for template-related speed issues. But in the absence of any unexpected speed problems, download speed with dual-view tables should be a non-issue.

           With option #5, where both views of the data are presented in one article, readers following a link to the article are immediately aware of both view options and can use the one that suits them at a particular moment. Its convenient “ ← Previous | Next →Go to Unitized table (all elements) Go to Periodic table ” nav tools make it a better solution than the two separate articles ever were; the sum is greater than the parts. If you want to scroll and see the unitized table, that’s all you see and deal with because it’s at the top. If you want to jump around in the segmented view using the new nav tools, you never have to mess around—or even see—the unitized table. And for those users who want to instantly skip between both views of the data, that’s now ultra-easy. Further, as there is only one “display” article, there is naturally only one venue for discussions. Greg L (my talk) 22:11, 20 February 2008 (UTC)

      2. Maybe this one is even better than my original proposition. Still have to think about loading issues though. --Quilbert (talk) 01:12, 21 February 2008 (UTC)
6. Add “divided“ features to “complete” to have both ways in one place, and add features to make it easier to jump straight to and within the “divided“ portion (this much has already been done.) Leave “divided” as it is and continue to maintain two articles.
   1. Votes:
7. Keep both articles as they are.
   1. Votes:
      1. The data in these tables doesn't change very often, keeping them manually synchronized should not be a large effort. Bryan Derksen (talk) 04:40, 20 February 2008 (UTC)
      2. This has worked for the last 4 years and is still the best proven solution, and takes zero additional effort to implement. Comments on alternatives 1-4:
         1. As said above, merging brings no benefits, actually decreases scrolling usability, exceeds size guidelines, increases page load time and editing preview time, and doubles server load. It does not remove the double maintenance of entries problem, and makes side by side comparison no easier.
         2. I use the complete table and feel it is the most faithful version and requires less skipping around, so I oppose its deletion.
         3. Personally I would be happy for the divided table to go away, but most likely it has too many supporters for this. It does not seem to me like horizontal scrolling is that hard - are there browsers still in use where it's difficult? With click-drag, or two-finger scroll on Mac, you can simply move diagonally and there are no added steps.
         4. Tables made from row templates is a possibility, but would take around 600 templates, and its effect on load time and server load needs to be evaluated. Block templates (e.g. 15 high and 15 wide) in a table matrix would take fewer templates, but also needs evaluation. Either would split up the unified table into pieces with unknown spacing that might not line up or be seamless; unless this worked out very well, it would damage the unified table. Generation from a flat data table of isotope entries could unify isotope data in not only these two tables, but also others like the Isotopes of <element> pages; this would be ultimately best, but will take a lot of development work. --JWB (talk) 13:44, 20 February 2008 (UTC)
            1. Sorry to disagree. Only one template would be needed, which implements a #switch condition. Just have a closer look at the experiment on my user page. All rows are named and all are defined in User:Quilbert/RowTemplate.--Quilbert (talk) 17:16, 20 February 2008 (UTC)
            2. I have started this now on User:Quilbert/Table of nuclides and User:Quilbert/IsotoneRows for elements 0–29. Feel free to carry on. Besides, I would prefer the lemma to be called “table of nuclides”. --Quilbert (talk) 19:48, 20 February 2008 (UTC)
            3. I support Quilbert’s work. A single database is clearly the way to go. The only remaining question becomes how to display the data—whether it should be in two articles or one. But with the single database, what little code remains for an article becomes extremely small so file-size issues—even a single article with both veiws—becomes a totally moot point. Greg L (my talk) 23:28, 20 February 2008 (UTC)
      3. Both the tables are useful, but no need to load both if you need one of them (for many users additional 50 kB can be too much). Synchro-editing is not difficult (or, at least, is not more difficult than editing of the template proposed by Quilbert - anybody who is quite smart to understand editing of this template is indeed able to synchronize the tables manually, but I am not sure that the converse theorem is true). In any case, the convenience of a reader is more significant than that of an editor. So, I vote for keeping both the tables separately, as them were before. I also support the renaming them to “table of nuclides”. --V1adis1av (talk) 22:39, 20 February 2008 (UTC)

Note, BTW, that a number of proposals above would violate the GFDL if implemented. The authorship information of past revisions needs to be retained to stay compliant. In instances where people are proposing to merge and delete an article, that needs to be interpreted as merge and redirect instead. Bryan Derksen (talk) 02:49, 21 February 2008 (UTC)

Comments to be translated into vote

I scripted some of the templates that, at the time, contributed to making these tables smaller in file size and easier to maintain. Unfortunately I am not able to follow the current discussion, so I cannot vote on any proposal, but I have a few principal stands:

• There should be a complete table to allow any reader to traverse, yes, the complete table. In the relevant scientific fields there are complete tables, and Wikipedia should provide the same and better.
• There could also be a simpler, less resource consuming version. I have experienced a variety of web browsers, operating systems and band widths and, in many situations, the complete table may be difficult to handle. To accommodate the variety of uses – and users – I think there should be a simpler, less resource consuming version. This could be a stripped complete table (if possible) or a table divided into smaller pieces.

Someone, at least one familiar with Femto's and my work, may translate this into a vote for the relevant proposal. --Eddi (Talk) 02:21, 22 February 2008 (UTC)

• While the objective is laudable, I don’t think the technology will cooperate. While additional work on the templates might make the edit code even tighter (for instance, this article is now only about 103 kB and maybe there’s a way to get it to 75 kB), the visual information still has to be presented on a screen. That’s done in HTML and the translation is done by the behind-the-scenes magic of the Wikipedia authoring environment. Right now, its about a 5:1 HTML/code factor. No matter how efficient one makes the templates, if you want all the little colored cells and the text inside them and the little pop-up text boxes when you hover your cursor over a colored cell, it’s always going to take about the same time to load the HTML to render the page. The only way to trim the download time is to present the information on-screen with fewer visual elements (less text in the cells, or no colored cell borders, or no colors, etc.) But who wants that?

  Anyway, file-size concerns are really beside the point. There are plenty of other articles on Wikipedia—like “United States”—that are as large or larger than this one (HTML download-wise) and no one has a problem with the download speed of those. So attempted fixes for file size is a solution looking for a problem. The issues we’re wrestling with have to do with there being multiple places to edit the exact same data, multiple places to look at the data, and multiple places to discuss things. Fixing these shortcomings requires change and change is seldom accomplished without controversy. Greg L (my talk) 03:45, 22 February 2008 (UTC)

If you look through Talk:United States you will actually find numerous complaints about poor performance and the need to split the page. Policy and most editors agree that these large pages should be split. That some of the worst examples of bloat have still avoided refactoring so far, is hardly an argument for going down the same road. --JWB (talk) 06:23, 22 February 2008 (UTC)

• I thoroughly checked all that out before using it as an example. Out of the 51 discussion topics, two pertain to size. One thread started Dec. 14th. And what was the conclusion of it all(?): United States stayed its current size! The main discussion thread concluded with this post: “What are you talking about? this article is practically the same size as the UK one, who cares if it is long; its an encyclopedia article not a dictionary definition and you must have bad internet if it takes that long to load, it loads instantly on mine and mines only 2mbps fast.”

  I also mentioned earlier, the 2007 Texas Longhorn football team article (which is bigger yet) and it has no file-size-related discussions on its talk pages. If everyone made the Internet so it was optimized for people with phone modems, it would pretty much suck today, wouldn’t it? I once had to battle some user over picture size because he used a phone modem and a 640 × 480 monitor. He made it his hobby to shrink the pictures on every single Wikipedia article he visited if it was too big for his taste. No Web site today lays out their pages to this lowest-common-denominator anymore and 1024 × 768 is the new minimum.

  As I’ve mentioned before (because you persist in raising this bogus issue), the 100 kB file-size recommendation is to keep regular, prose-based articles from becoming boring. Reference tables don’t suffer from this “boredom” issue because no one reads them from end to end. There’s only one valid size-related criteria to judge this on: does this article load fast enough for the vast majority of users. If it does, then we’re doing our job right. Past performance problems seem to have been associated with a lack of proper use of templates and all that seems to have been resolved. Can we move on now please? Greg L (my talk) 07:44, 22 February 2008 (UTC)

Some people do have "bad internet". (Mine is pretty decent, but less than 2mbps.) We do try to make things accessible to them, as well as people with other disabilities. Lack of good horizontal scrolling is also a technical problem that many or most people's computers no longer have, yet we have a duplicate divided isotope table to cater to them. On the other hand, not merging the two tables into one article does nothing to hurt people with fast connections and large screens.

The 100k limit (in fact, you start to get warnings when saving 40k or more) is not solely to prevent boredom; where did you get that idea? It is for a number of reasons, including keeping down total server load, as well as keeping down response time (viewing or editing) in low-resource situations. Tables are mentioned separately only to make an exception that you are not forced to split them when they cannot be split without impairing usefulness.

I suggest you stop citing violations that enforcement has not caught up to yet as positive examples, and instead just respect stated Wikipedia policy. This is like noting that some articles continue to have huge numbers of Citation needed tags, and concluding that this is just fine and that we ought to leave more in our article. --JWB (talk) 09:51, 22 February 2008 (UTC)

• While I've always seen the divided version as a mere supplement to the 'proper' complete table, I'm against the removal of either of these pages. Both have their merits.

  The main reason for having separate pages, however, is not to let readers select an appropriate display format from a variety of options. Rather (this is a Wikipedia-wide consideration), it's to enable them to avoid viewing (loading, navigating) what they're not interested in.

  So, I definitely don't subscribe to an "all in one place" view. Since the content of these tables is the same and the reader usually only needs one version, this means there should be two separate pages. (If maintainability, server load, or page size can be improved by using a master database template, I think I'd welcome it, but that's really a different, secondary issue.) Femto (talk) 14:03, 22 February 2008 (UTC)

• “…it's to enable them to avoid viewing (loading, navigating) what they're not interested in.” That’s exactly what you get with the layout of the current “complete”. If you want to scroll and see the unitized table, that’s all you see and deal with because it’s at the top. If you want to jump around in the segmented view using the new nav tools, you never have to mess around—or even see—the unitized table. And for those users who want to instantly skip between both views of the data, that’s now ultra-easy. Greg L (my talk) 20:42, 22 February 2008 (UTC)

Providing the option to avoid opening content that you don't need is an actual convenience (not only) for people with a slow connection. For people with a fast connection, there is no real advantage or difference between instantly jumping up and down as opposed to loading another article. I maintain the first convenience far outweighs the other. Femto (talk) 12:24, 23 February 2008 (UTC)

Generating table via templates

I'll discuss Quilbert's and related ideas here to avoid further cluttering the vote section.

At first I assumed it would use a differently named template for each row section or block, but he is putting all the data in one template, and returning different subsections of the data using a switch statement. Therefore the template will be at least as large as the complete table in the current article. It's also an open question how fast hundreds of evaluations of a very large template will be. If the MediaWiki software is smart about it, it may not be too bad, but it would also be easy for the server to handle such a case badly.

I do not see any seams in the prototype so far, so for the moment let's assume that issue is solved.

Greg describes the issues as "multiple places to edit the exact same data, multiple places to look at the data, and multiple places to discuss things". Evaluating Quilbert's proposal on each of these:

1. Quilbert's method provides a single place to maintain the data, which Greg's work so far did not. However finding where a given nuclide entry is for editing purposes would become a bit more complicated. It would have to be well documented in prominent locations, and as with any convention or procedure, there is the possibility of inexperienced or less careful editors screwing it up. I think this is manageable and not insuperable, but note that Greg's major argument for change is that the situation existing now is too complicated for editors to use.
2. Quilbert's method also makes multiple places to look at the data easy; we could easily have an article with complete table for me, one with both tables for Greg, and one with only the divided table for Rebroad, with viewers who are only interested in one table at a time not having to load and scroll through the other table. We could even also easily have an article with the table divided into chunks double the size, for those who have wider screens but still don't want to scroll horizontally. The only limitation (on results, leaving aside performance) is that the blocks defined in the data template cannot be subdivided, and so the block size must initially be chosen wisely. Also, it would not enable still more different formats such as rotated 45 degrees, but then no scheme other than generation from a data table with separate entries for each nuclide would enable this. (I've considered both 45 degree rotated and stable nuclide-centered formats, and have prototyped the latter a bit.)
3. There would be a minimum of two articles involved, the data template(s), and at least one article displaying the table(s). In fact, there would be, and already are, multiple lower level templates like Template:Iso1, with the possibility of discussion at the talk page of each. Strictly, one could claim that none of the solutions, except a hardcoded article using no templates at all, inherently eliminate the possibility of multiple discussion pages. The possibility of multiple discussion pages always has to be handled by notices and/or redirects in the discussion pages, and editors will always have to respect some conventions for using the Talk pages. --JWB (talk) 07:00, 22 February 2008 (UTC)

• But… how do you really feel about all this? Greg L (my talk) 07:47, 22 February 2008 (UTC)

You might want to have a look at the result of my work at User:Quilbert/Table of nuclides. The wikisource for each display method (complete, split, split (wide)) would be around 13 KB in size (when all occurences of {{User:Quilbert/IsotoneRows|…}} are replaced by {{IsotoneRows|…}}). --Quilbert (talk) 18:07, 22 February 2008 (UTC)

Yes, as I said, the displayed table itself has smaller source, but the template holding all the data (User:Quilbert/IsotoneRows) is at least as big as the existing table, currently 57k. I'm not saying that this is necessarily a bad thing; I'm just continuing to think about whether spreading the data over multiple templates would be better or worse.

I'm not sure if Greg's question is sarcastic, or if not, what he is asking. --JWB (talk) 18:34, 22 February 2008 (UTC)

I just wanted to inform you that I had finished the “templatization”. I don’t know what Greg is asking, he is obviously thinking that you are not being honest.

Of course, the data could be spreaded. But I don’t like the idea that much … 57 kB isn’t that big after all, what would you say? --Quilbert (talk) 19:23, 22 February 2008 (UTC)

No, 57k is not much bigger. Size of finally generated HTML should not change at all. I wish we had a way to tell how much template evaluation is loading the server, but just eyeballing load time, performance seems OK.

Putting data in multiple templates (for example one template per element) is always something we can consider later. For now I think one data template is good, and makes it easier to make further changes.

I still have ideas about changing the Iso1 template to improve size and performance, but those should be entirely independent of this change.

What should we call the IsotoneRows template? Maybe just Isotone to reduce size?

Do you want to keep the column size at 15 or change it? I will stay out of that question since I'm not a user of the divided table.

Anyway, congratulations on your good idea and quick implementation. I have no problem with using it immediately in the article(s). Should we consider the change from data hardcoded in each isotope table article to data from isotone segments stored in template(s) as now adopted by consensus, and proceed from there? That would be fine with me. --JWB (talk) 16:24, 25 February 2008 (UTC)

How about Isotones? I assume this is ok and go ahead, but it still can be changed of course.

By Greg’s evaluation I would say the column size is good as it is. By the answer to my request on m:Help talk:Template#Expansion at load time? I believe the templates are only expanded once every time the code is saved and then the expanded code is cached. So there ought to be no worries about server payload. Plus, even before for every nuclide cell the template Iso1 had to be expanded once. --Quilbert (talk) 19:25, 25 February 2008 (UTC)

done with moving the template. The code size is now 30 KB. The size warning has gone away :) --Quilbert (talk) 19:33, 25 February 2008 (UTC)

Great, thanks again! Isotones is fine. Just wasn't sure if adding levels of template calls had any effect or not. --JWB (talk) 21:47, 25 February 2008 (UTC)

• I was thinking that JWB’s arguments have become tedious, his objections have been noted, and he’s made his feelings abundantly clear. Wikipedia policy regarding “assuming good faith” is intended to help editors properly deal with their first encounters with others who are on the “other side of the fence” on an issue. After someone has repeatedly demonstrated a consistent M.O., one can deal with such individuals as required. It seems clear to me that JWB’s objections citing technical issues like “file size” are nothing more than chaff and decoy to the central issue: he really really likes having an article (“divided”) that features only the segmented view of the data and fears that an article featuring both unitized and segmented views of the data threatens the viability of any article featuring only one. That much is abundantly clear now to me now.

  I fully support Quilbert’s work and am deeply appreciative that he read the arguments of the proponents and detractors of the various proposed solutions and… 1) recognized how to resolve the problems, 2) has the skills required to help, and 3) is willing to donate his time as a volunteer to actually do something about. This exploration into this new and (probably) better way of accomplishing this is going forward. It’s time JWB, to accept that reality and to recognize that we’re trying to make progress here. You need to stop throwing your sabot (wooden shoe) into the gear-works in futile attempts to make things grind to a halt. Quilbert, please contact me if there’s something I can do to help. Greg L (my talk) 20:38, 22 February 2008 (UTC)

• P.S. What I’m seeing on your demonstration site at User:Quilbert/Table of nuclides really shows off the power of your new approach. It’s less than 50 kB too! I like what I see. Greg L (my talk) 01:46, 23 February 2008 (UTC)

New example via “Quilbert Method”

• I’ve temporarily upgraded “complete” so it uses Quilbert’s “User:Quilbert/IsotoneRows” template for its source data. All changes here are proposals for evaluation. As you can see, the article size is now only 38,876 bytes! It loads very quickly for me. Quilbert’s approach makes a great deal of sense. A unitized article is naturally the only place where discussions would occur. Further, the template is the only place where changes to the data occurs; one only has to make one edit to effect a change even though there are multiple views of the data being used.

  The new page requires no horizontal scrolling on 800 × 600-pixel screens. This is even smaller than the current standard for Web use (ABC News, CNN News, and MSNBC News, to name a few, all require 1024-pixel-wide screens to avoid scrolling). By “no horizontal scrolling,” I am of course, referring to situations where the reader elects to skip over the Unitized table, which always requires horizontal scrolling (unless you’ve got multiple monitors totalling at least 3,856 pixels in width).

  As I mentioned above, with this method, both views of the data are presented in one article so readers following a link to the article are immediately aware of both view options and can use whichever one suits them at a particular moment. Its convenient “ ← Previous | Next →Go to Unitized table (all elements) Go to Periodic table ” nav tools make it a better solution than the two separate articles ever were; the whole is greater than the sum of the parts. Further, the new nav tools I added lately make it much easier for the disabled. If you want to scroll and see the unitized table, that’s all you see and deal with because it is conveniently located near the top and is the first thing you encounter when you start scrolling. For “click-happy” readers (I’m one of ’em) who often like to jump around in the segmented view using the new nav tools, we never have to mess around—or even see—the unitized table. And any reader can now instantly skip between both views of the data without having to go to an entirely different article.

  Although this is “change” (which rarely occurs on Wikipedia without objection), it doesn’t appear to me that there are any downsides to Quilbert’s way of maintaining data tables and displaying the information. I think it’s a fabulous way of doing things and its advantages are obvious and compelling: there’s only one place to visit for reading, only one place where users would naturally discuss issues, only one place to edit the data, and the article’s code becomes exceptionally tight (at 38,876 bytes, it’s smaller than it’s ever been before). This has my enthusiastic support. Greg L (my talk) 22:03, 23 February 2008 (UTC)

• P.S. I temporarily swapped the positions of the segmented and unitized tables and also sandwiched the unitized section with several quick-nav links. Now, the segmented table is at the top. I hope that this might be more appealing to advocates of the “segmented way” of looking at the data. As before, the changes here are proposals for evaluation. The the few extra nav tools and the additional introductory text slightly increases the size of the article (667 bytes after some code compaction), but at 39,539 bytes (38.61 kB), this article is still more compact than it’s ever been before. Greg L (my talk) 18:59, 25 February 2008 (UTC)

• P.P.S. And now that Quilbert put the template in the article’s namespace, (data is edited at Template:Isotones) the entire article totals 29,632 bytes (28.94 kB). Greg L (my talk) 21:00, 25 February 2008 (UTC)

Vote on merge of Isotope table (divided) (now after conversion to isotone templating)

Ok, now that we've restructured the nuclide data so that one data set can be used in multiple places, let's get back to the merge proposal itself. This innovation eliminates one of the arguments for the merge, which was that the merge would allow editing of nuclide data in only one article instead of two (or more). The remaining issue is whether to merge the two articles with different presentations of the same data into the one that currently displays both.

Please vote for or against the proposed merge of Isotope table (divided) into Isotope table (complete). For decidability, clarity, and process as specified in Wikipedia policy, this is a yes/no vote only on the merge, and not on other proposals later mentioned during the discussion, such as

• creation of more isotope table articles (whether drawing data from the same Template:Isotones or not), such as
  • article containing multiple tables (e.g. complete and divided)
  • separate article for each segment of divided table
  • doublewidth divided table
  • diagonal table (rotated 45 degrees)
  • table with each isobar centered on its most stable nuclide
• renaming of some isotope table articles (e.g. Isotope table (divided) to Table of nuclides (divided))
• deletion of some isotope table articles,
• enhancements such as navigation aids within the isotope table articles,
• or implementation changes such as restructuring of the data template(s).

The later or hypothetical proposals can have their own consensus building or vote if needed, after this merge proposal has been settled. --JWB (talk) 22:12, 25 February 2008 (UTC)

1. Merge Isotope table (divided) into Isotope table (complete).
   1. Votes:
2. Do not merge Isotope table (divided) into Isotope table (complete).
   1. Votes:
      1. Do not merge Many users prefer one presentation at a time, as also mentioned by Femto, and there is now no reason to disallow this. If some users prefer both presentations on a single article, they can create a third article to their liking, with little extra overhead due to the templatized data. Wikipedia supports periodic tables of many formats in multiple articles and templates, and this is similar. JWB (talk) 22:12, 25 February 2008 (UTC)

What sort of games are you trying to play now with your “[We’re not considering] enhancements such as navigation aids within the isotope table articles” and “[Users] can create a third article to their liking”? Is the question Merg vs. Not merge? Or is it Merge vs. Revert “complete” to what it was a month ago and keep “divided” like it is after you’ve ‘adopted’ all of Quilbert’s and my hard work? Greg L (my talk) 22:55, 25 February 2008 (UTC)

Greg, again, please read WP:PA and WP:OWN and respect the rules and your peers. I can't tell exactly what you are getting at. Yes, the question now being voted is merge vs. not merge, it says that plainly. I'm not sure what the reference to a month ago is; apparently you changed the coloring of two isotopes then, which has nothing to do with the merge. You did the merge 8 days ago, and were not allowed to redo it after reversion until consensus was reached, but you did anyway; the fact that it is in the article now is not an argument that it should stay, it just shows you are ignoring the rules. --JWB (talk) 23:46, 25 February 2008 (UTC)

• Wow… Your MO is at least consistent! After that smokescreen of wrapping yourself in the flag of “Truth, Justice, and the American Way”, quoting Wikipedia policy, and pretending to counsel another about “respecting the rules and your peers,” it’s been pried out of you. Your supposed Up-or-Down vote you invited us to vote on seemed rather simple on the face of it: “Merge vs. No merge.”

  Suprise! You were actually planning to implement it as if a “No merge” vote was really “Revert ‘(complete)’ to the state it was at before I worked on the article but keep ‘(divided)’ in the state it’s currently in after you ‘adopted’ all of Quilbert’s and my ideas and hard work.” Just pardon me all over if I wait until someone a teensy bit more trustworthy steps in to help fashion a consensus regarding what to do about ‘(divided)’. I’d volunteer to do it myself but the steaming example you just served up may have prejudiced everyone as to what I might try to do. Greg L (my talk) 02:05, 26 February 2008 (UTC)

Yes, I am still asking you to follow policy and refrain from personal abuse. I'm still not sure whether you understand what is and isn't the merge. I'll try to explain again:

• Quilbert's templatization of the data is an enhancement applicable to both articles and both tables, and was adopted by consensus.
• Merging the two articles (moving divided table to "complete" article) was and continues to be in dispute.
• Nav links, extra color keys, and non-imagemapped periodic table image you added are also independent of the question of merging the two articles. This stuff was about 10 lines of source when I first saved it for you and may be a bit bigger now. We add stuff like this to articles all the time, and yours is a relatively unsophisticated example which does not use normal Wikipedia navigation templates or provide imagemap links, and provides little more navigation functionality than default table of contents links, yet you accuse people of stealing it as if it were something special, and equate it to restructuring the data which was a conceptual breakthrough plus thousands of lines of editing. I have tried to make it clear I don't care that much one way or the other about this stuff, but just do not want it to be lumped with the unrelated merge in order to make that merge look better. --JWB (talk) 02:59, 26 February 2008 (UTC)

• “Personal abuse” (as in Wikipedia policy regarding no personal attacks) doesn’t mean others have to accept horse crap from an editor over and over from you while also requiring us to pat you on the head after your little stunts. Saying that I think your position is without merit and your tactics are underhanded falls about a light-year short of “personal abuse” as defined by A) common sense, and 2) Wikipedia so don’t even start trying to hide behind the apron strings of that one.

  → Regarding your first bullet point: if you define “consensus” as comprising you and one other human being: the guy who did all the hard work, Quilbert, that would be true. But it isn’t. Like most everything else from you, it’s pasture patties. All your exchanges are memorialized above at #Generating table via templates. That’s just you and Quilbert talking up there. Call it for what it really is: I liked Quilbert’s template and knew it was the better way of doing it and that no one would complain since the advantages were obvious. You did too and revised “(divided)” the same way—and after I did. So ease up on this effort to paint a picture that you’re edits have been anointed with the benediction of “consensus”. It’s so damned tedious pointing out the details of every little misrepresentation of yours.

  → Regarding bullet point #2: More pasture patties. I did no “merge.” A merge (which deletes “divided”) is what you were trying to avoid above by trying to deceptively game the vote only a few hours ago! As it currently stands, this article is a multi-view and “(divided)” is a single-view page. But they both exist (and shouldn’t).

  → Regarding bullet point #3: Not even worthy of a response.

  I’m quite done dealing with you directly. Wikipedia is supposed to be a fun hobby and singularly shouldering the burden of having to deal with you is highly un-fun. Don’t take that as an invitation to haul off and undo all that’s been done here. If you feel that “(complete)” threatens “(divided)”, that’s tough; what occurs here will be done by consensus. And by consensus, I mean as Wikipedia defines it, not you. I suggest you take a hint and get out of the business of trying to define the nature of any votes conducted here because your tactics are profoundly biased and questionable. P.S. In case you’re confused, that last one wasn’t a “personal attack” either; it’s the simple truth. Greg L (my talk) 05:19, 26 February 2008 (UTC)

Sorry, I am not going to be tempted into returning abuse.

If anyone objects to Quilbert's templatization, they can speak up and/or revert it, then we will discuss, and if that does not reach consensus, vote if necessary. Nobody has objected so far and some of the other editors expressed interest in this option in the previous poll. Please don't try to find disagreement even where there is none

In fact I have not updated Isotope table (divided) to the Template:Isotone scheme so far. I'm not sure why you are angrily asserting something that you or anyone else can verify is false in a few seconds, as well as irrelevant.

You seem to continue to think I'm somehow favoring the divided table. In fact I like the unified table better and have said so clearly a couple of times. I do not want the divided table merged into the same article, so I can continue to load and read only the unified table. If you like your presentation better, please go create your own combined article, as the data templatization has enabled you to do, rather than continuing to damage the usability of this one.

You are not allowed to perform a disputed merge before a consensus in favor of it has been reached, and addition of the divided table to this article will be reverted until then. So far I have tried to reason with and accommodate you rather than taking the proper action, and for my trouble have gotten only the sort of responses you've posted above. --JWB (talk) 07:13, 26 February 2008 (UTC)

• Well, your actions (furiously improving “divided”) don’t quite match your words above about which one you prefer. Anyway, that doesn’t really matter. You’d be wise to not tamper with “(complete)” until a properly framed vote can be conducted. To accomodate those with slow modems, proposals are being advanced to keep both versions and use a disambiguation page. It may also be that a consensus will develop to delete “(divided)” as being entirely redundant given that “(complete)” gives users both views. Either way, you shouldn’t assume that you can liberally “borrow” others interface ideas and improvments to articles and then delete it from where you “borrowed” them from. It is most appropriate to give others an opportuntity to weigh in. You’ve been nearly appoplectic about resolving things in a matter of hours; these things take many days—if not weeks. Lighten up. Greg L (my talk) 08:10, 26 February 2008 (UTC)

aside: nuclear isomers

So far, when the most stable and the second most stable nuclear isomer are in the same color category, Iso1 is used. I wonder why. Please use Iso2 instead and double the color statement (except when both would be white). I have changed Iso2 in that a dotted border is displayed in that case. I have found this to apply to at least Xe-133 and Rh-102.

My second point is: When do we display white borders? When a nuclear isomer has been detected, even when it is extremely short-lived? --Quilbert (talk) 04:34, 26 February 2008 (UTC)

• Well, while we’re on “asides” (as in actually getting something worthwhile done), I’m all for it. So I’ll toss my question into the hat: Why is there a “10 k–103 M” year color and then a jump to “>700 M” years? What happend to 104–699 million years? Are there currently no isotopes with that half-life? Is there a well established scientific theory showing that there can’t be a half-life in that range? Either light blue needs to reach up or violet needs to reach down. I don’t think anyone wants to add another color do they? Greg L (my talk) 05:27, 26 February 2008 (UTC)

  P.S. I’ll bet either JWB or V1adis1av can answer both our questions. Greg L (my talk) 05:42, 26 February 2008 (UTC)

Apparently, that is the gap between Sm-146 and U-235. This comes from the “natural radioactive” category in the original data, which meant nothing but long-lived enough that it still occurs naturally (see my newbie request above). It can’t be ruled out that there are nuclides within the gap near the hypothetical island of stability, but so long, that is ok. --Quilbert (talk) 07:50, 26 February 2008 (UTC)

Merging objectives

I’ll try to construct a proposal everyone might be satisfied by:

• My first point is somewhat unrelated and not even new: We should move to “Table of nuclides”. The articles that at the moment exist under that name, better fit “Isotope lists”.
• Table of nuclides should be a disambiguation page that links to (combined), (divided) and (complete), maybe even (divided, wide), with proper remarks about their designs and download sizes. It also should link to the non-graphical Isotope lists (now “Table of nuclides”).
• All talk pages of the three or four representations should redirect to the talk page of the disambiguation page to avoid unnecessary confusion. Maybe even the template’s talk page should redirect there. Current discussions here and on (divided) can be archived on a subpage. The articles themselves get the usual disambiguation notes.

I hope that from here, we finally come to a consensus. --Quilbert (talk) 08:37, 26 February 2008 (UTC)

Thanks again and here are comments on your three proposal points:

1. "Nuclides" is indeed more correct than "isotopes" which strictly speaking refers to isotopes of the same element, though colloquially "isotope" is still often used for the less known "nuclide". The Knolls paper chart I have is headed "Chart of the Nuclides"; it is very similar to the table we currently have except that more information is packed into each cell, and the n and p (or Z) axes are transposed so that rows are made of isotopes not isotones. (The choice of isotones for rows in our charts is something else I'd like to discuss later when we get a chance, and I've also prototyped a separate special-purpose partial chart User:JWB/Isotopes by isobar with isobars on rows and all beta decay towards the vertical center line.) The articles now misnamed "tables of nuclides" could be renamed something like "Isotopes of elements 77-93 (data page)"; maybe they should be harmonized with the "Isotopes of <element>" series of articles.
2. Periodic table is a good model; the article is larger than a disambig page, but explains what the periodic table is and displays or links various formats of the periodic table; the main difference is that nuclide tables are bigger, so that links should be favored over inclusion of large tables. There is even already an existing unnoticed article Chart of the nuclides which attempts to explain the concept and is already at a correct name; simply adding links would make it a working portal page immediately, and we could continue to refine the article text.
3. What's most important is that all the talk pages offer a "site map" (probably a template itself) explaining the structure of the nuclide table articles and talk pages, and links to those pages as well as other relevant articles/discussions and WP:WikiProject Isotopes. I think the redirect structure is secondary to explanation, will not eliminate all confusion, and may introduce a little confusion of its own. I trust whatever redirect structure you come up with, and am happy for this to be in your capable hands. --JWB (talk) 00:01, 27 February 2008 (UTC)

• Lay something on us Quilbert. I think we could all use some intervention by someone who possesses the skills to make a difference and further, is willing to do some heavy lifting here. Thanks. Greg L (my talk) 17:36, 26 February 2008 (UTC)

• Quick feedback: I’m looking at this site using Safari on a Mac but I usually see what Windows users see when I use FireFox. I assume you are aware than many cells in the unitized table are stretched vertically. The offending column is apparently always the last one in the segmented tables (N14, 21, 44…).

  And then good news: when the Wikipedia server isn’t burdened and other articles are loading quickly, the new “complete” page loads and refreshes very quickly too. Greg L (my talk) 18:00, 26 February 2008 (UTC)

Oh, thanks for noting, that happened when I added the Category:Isotope tables templates to the Template:Isotones. It should be ok now. Looking at the category, you will find that I have created some more templates for the actual tables that implement the data, as they are planned to appear in different places (for example, Template:NuclidesDivided, 0-14 is currently used here and on (divided)). We have four layers of templates now, the color and text templates, the cell templates, Isotones and the tables. --Quilbert (talk) 19:26, 26 February 2008 (UTC)

• It looks really good Quilbert. Greg L (my talk) 19:54, 26 February 2008 (UTC)

• Quilbert, I just am not experienced enough with templates to attempt odd new things with any confidence. Could you add a colored border to one of the cells in the Template:Isotope colour chart? I’d like to make specific mention of that example cell in the third paragraph. Greg L (my talk) 20:28, 26 February 2008 (UTC)

• To all: Today, I remembered my fundamental reason for originally wanting a page featuring both views of the data (segmented and unitized). I realized that it had escaped me to ever explain that reason here in this venue.

  We editors here are all intimately familiar with these tables. But when I first encountered these tables, it was at “(divided)” and I didn’t quickly understand what I was looking at. I tend to skip over the introductory text on Wikipedia and wade down into the meat articles to get a feel for what I’m encountering. I think this is something many of us tend to do at times. As I scrolled down through the different tables, on first glance, they are separate tables that seemed to represent different data sets of some sort. So I scrolled back up and read the introductory text, which referenced the “(complete)” table.

  Well, one quick look at “(complete)” and I had my “ah HA!” moment. I instantly understood that the segmented tables were just pieces of a huge, contiguous, unwieldily single table. Now, I’m no dummy; I’ve got 15 patents to my name and they’re all “deep” in the technological fields. So if it took me a moment to figure this out, I’m confident many novices landing on these pages for their first time will have the same experience.

  This was the genesis of my desire to get both views into a single page. It would be a place where I could link to from other articles. I wouldn't have to land the reader in “(complete)”, where they instantly get the “ah HA!” but are burdened with its unwieldily nature. I wouldn’t have to land a reader in “(divided)” where some would have difficulty quickly grasping the basic concept (that the tables are fragments of a whole). Instead, one good scroll through a dual-view version would expose the reader to the concept in one fell swoop and provide instant access to the segmented tables.

  With Quilbert’s approach, both versions of this article can coexist and serve a valid purpose. If editors choose to, readers can be directed to the dual-view version where a link would make readers aware of the divided-only version. Since this is Quilbert’s vision—and since this is where he is currently headed—I’ve added a link in “(complete)” that points to “(divided)” and I’ve withdrawn the merge-proposal tag from “(divided)”. Greg L (my talk) 19:52, 26 February 2008 (UTC)