User talk:DePiep: Difference between revisions - Wikipedia

You may want to increment {{Archive basics}} to |counter= 12 as User talk:DePiep/Archive 11 is larger than the recommended 150Kb.

I have not been paying much attention to the extensive discussion of periodic table layouts, so please let me know if the following is part of one of them, or where else I should ask, but you seem to be doing a lot of work on these sorts of things. In the article for each element, the periodic table in the infobox, is color-coded according to a set of categories. The colors are defined in {{Periodic table (32 columns, micro)/elementcell}}. My problem is that the color of hydrogen makes its space virtually invisible against the white background on which it is displayed. |category=diatomic nonmetal gives color #e7ff8f, very hard  to  see or click the small space unless you know where to look. At least for the nitrogen and oxygen spaces, their locations are knowable from the surrounding darker colored ones on multiple sides. But hydrogen is fairly alone. I'd welcome any change of color but did not want to change it too WP:BOLDly..I'm not sure what other layouts are being kept in sync. DMacks (talk) 04:45, 14 January 2016 (UTC)[reply]

At enwiki We use a set of 11 colors for what we call "metallicity categories" in the periodic table (PT). See the legend in Periodic table. This set is the same over all PT's, both html tables and images. Could be a 40-50 together. Of course this consistency is very helpful in an already complicated topic. In specialised areas and in other topics (like blocks) a different legend-set is used.

Now you happened to walk into a new discussion about these colors (you have seen). Main issue with current set is bad contrast (re WP:ACCESS): background too dark. What you describe is an issue too (distinction from bg), and already mentiooned somewhere in there.

Now picking an other set (or just chaning one color in this case) is a huge process. There are many requirements to take care of , some even contradicting. There also is: contrast with fontcolors, distinction of neighbor colors, stressing main border area metalloids, colorblindness, and more. There is no single algorithm/process/recepy to reach an outcome; cyclic is better and still compromises might be needed. The problems are especially huge because of the number "11 categories": four would be a lot easier!

We have started the process by first focusing on: the 11 distinguishable background colors (status in User:DePiep/pt-2016). A lot of extreme errors are gone already. More tuning to do. Next step would be the other requirements like good contrast with fonts, and -- relevant for your point -- effects in big/small PTs, and re background. But today these 2nd set of checks is not processed at all. Also, I'd like to research more about such issues in the process (color perception).

So yes, this is a topic already in discussion, together with 20 other issues. To be a good website, we can not compromise on these access issues (but maybe elsewhere). And it takes loads of time. On my clock, and on the calendar. -DePiep (talk) 05:47, 14 January 2016 (UTC)[reply]

Sõ, there is no bold & quick solution b/c the color is embedded. Maybe, while working on this, I'll find a interim improvement. -~~

Hey, I just stumbled today on my proposal from the last year and I thought that it was certainly better than what we have today. I recall there are no immediate problems to solve before it goes live. I think it would be right to launch it into the main space as it is currently the only version that we have that complies with the color design requirements you introduced me to back then. I'm not immediately lauching it because you were to it as well and I wouldn't want this to create any uncomfortable feelings but you don't seem to be working on it at the moment, either. How about this: I'm launching my current version and then wait for you to finish yours; then when you do, I will stay away from the discussion on if we should use yours instead? (I want to make it absolutely clear this is not a competition to me and I am ready to step down when there is something to step down to.)--R8R (talk) 13:11, 21 July 2017 (UTC)[reply]

R8R The setup we reached last yer still have some flaws. I'm breeding on a new buildup of colors, but it requires much more checks & thoughts. -DePiep (talk) 17:10, 1 August 2017 (UTC)[reply]

Are those prohibitively important flaws?--R8R (talk) 21:25, 1 August 2017 (UTC)[reply]

No, but better do it right once. -DePiep (talk) 22:12, 1 August 2017 (UTC)[reply]

• R8R Some issues, I think of now:

1. Testing for contrast: Still looking for a comprehensive template that does contrast-checking (W3C levels) easy & right.
2. Generate RGB <- -> HSV colors: still looking for acomprehensive template (convert color values both ways). Did not come to build it in Lua myself.
3. Whichever category colors we propose: must be checked for contrast against 1. font color black and wikilink blue 2. Also, against legend colors (we use for state of matter): red, green, grey. Legend colors may be changed too.
4. We use "lighter shade to mean: predicted". That may be too much of a requirement (reducing our degrees of freedom too much). Need arguing this into a different rule (on how to show predicted categorising).
5. Better check for: contrast with white-ish background (esp yellows are tricky; see current H cell in the infobox, unbordered).
6. Choosing a principle from left to right ordering in the PT: checkered = better border distinction in neighbouring categories versus gradual change to support the trend we're showing.
7. For options & solutions, I've bought a copy of colorbrewer (on map coloring), which has a whole new analysis and approach. Especially since we need to cover ten categories. Checks for colorblind issues required too.

I must add, that last months I was distracted onwiki too much by petty issues... (bad). Also, RL occupations left little time for setting up this list of requirements and further argument.

-DePiep (talk) 11:10, 2 August 2017 (UTC)[reply]

There are many converters online. I have built {{HSVtoHEX}} in-Wiki. May also build {{HEXtoHSV}} if you want me to.

My current colors pass contrast test against black and wlink blue. Green for liquids is difficult to get contrast with other colors with, so changed it to blue. Also used a darker shade of red for gases for the same reason.

Lighter colors seem fine to me. They are auxilliary to the main colors anyway. If we put apart cyan and green (etc.), this should be no problem at all.

Seem to have agreed on color order over time. Maybe not even checkers (not too pleasing aestetically for me at least), but a more distorted order. See even the main-page color preview at colorbrewer.

I may dive back into it and try a new approach sometime soon (well, I hope I may). Should I, since you've been so busy lately?--R8R (talk) 12:25, 2 August 2017 (UTC)[reply]

Of course you're free to go any route you like. It's just, I want to (planned to) check against points I just mentioned, and more.

The help template is not core of course, they are just to check. But to check every single set (10+1 backgrounds) against two text colors + four SoM fontcolors is = 66 checks. Before checking, one needs to develop (compose) colors, systematically. Is what HSV is useful for, but that must be converted to RGB too. That's 11+4 color developments per proposed set. Then there is the order variant proposals (AM-NG). So a templates would be helpful, as automation.

The lighter prediction colors are a reduction of freedom. If we keep that principle, ~each bg color must have a 2nd color, tested. (maybe not all - that's analysis to do). INstead, we could skip this test requiremnents by thinking of an other predicted-marking.

And this: in yellow hues, there is only one option for its lightness (too difficult to distinguis two yellows; the other hues can have 2 or 3). For this reason, I thought of using the yellow one for metalloids (unique hue, for unique & border category). btw, yellow probably should have higher V per colorbrewer (may stand out this way).

Need to analyse bordering colors (bordering categories). Bad situation today: group 3, with 3 reds! More such tricky ppints?

Sequence AM-NG should be checked being circular (eg, next to NG, AM returns as in Janets Left Step).

Can we use same x-S-V for all? Colorbrewer analysis (legend type). Does the grey (unk) conflict with other grey meanings & colors? Why does colorbrewer use brown?

note to self: check other wikis FA-periodic tables. Is our categorisation scheme stable? (current NNNM talk is OK -- note that new category==new color).

And this is just from the top of my head. Colorbrewer and access-colorblindness could jeopardize any setup. So I wanted to build all these arguments from scratch.

-DePiep (talk) 13:09, 2 August 2017 (UTC)[reply]

To illustrate the process. this article (+talk) has this color-development history (I did with YBG). The issue was way more simple, and still many angles had to be checked & improved. A dozen colors sets were needed for a final one. -DePiep (talk) 13:57, 2 August 2017 (UTC)[reply]

I came as far as this: User:DePiep/PTCC -DePiep (talk) 14:01, 2 August 2017 (UTC)[reply]

• See User:DePiep/PTCC. I've added basic content. Needs a setup for systematic color creation & checking (like contrast), to manage multiple lists. That's checking templates and color-building descriptions (motivations) needed.

You're invited to improve this setup. Once the setup is stable, it should go to WP:ELEM project (subpages).

This implies renewed development, a restart from the 2016 setup. I'm not sure if I've convinced you yet. I also looked at the one you made in 2016: colors look bleak, and therefor more difficult to distinguish. (colorbrewer has different solutions, given the higher number). -DePiep (talk) 16:47, 2 August 2017 (UTC)[reply]

It seems I'm more busy than I'd thought I'd be. Alas.

If you write an extensive list of the templates you need in Wiki code, I'll probably write them over time.

You have actually convinced me that there could be improvements to be made. I think I could (if I had time) try to build a better scheme. I'll list some comments on my current scheme anyway (so you could learn something from my experience you could use when you try to make a better version):

1. The scheme complies with all color contrast standards.
2. The scheme is a constant x-S-V. I couldn't increase S much and V is already at its highest (and lowering only produced even bleaker colors). A major limitation is the wikilink color, being so light. I think we don't need to keep S and V constant (if we do, we can't have brown, for example). Maybe we'll need to employ a different standard (darkness, for example).
3. Another limitation is the need to show the colors for states of matter; we could have better colors if we didn't have that limitation. Green for liquids is so prohibitive I couldn't keep it (used dark blue instead). If there are any limitations to get rid of, I'd suggest this (not too important in my opinion anyway) and not lighter colors for "(predicted)".
4. We will definitely do better if we get rid of colors sequenced as either a straight circular sequence (my current suggestion) or a checkered one (yours). Your work w/ YBG shows that very well.
5. A new scheme should indeed pick the darkest colors for all borderline categories. The current scheme is very weak. Mine also could use improvements (boron and hydrogen, for instance).

I think codebrewer uses brown because it's a very distinct color. Better than two reds, for instance. I guess that's also with their pink is so much brigther than their red: so it stands out more.-R8R (talk) 17:00, 8 August 2017 (UTC)[reply]

ColorBrewer daringly uses colors with different x-S-V values (unlike we do in the 2016 proposals, as I advocated). Especially when 9 or 10 colors used. It has the advantage that colors are more outspoken and so more recognisable. (It also may be required once colorblindness is taken into account: that sort of forbids certain colors).

Maybe a good test wqould be: crete a blind (text-less) PT, see if one can bring home the colors. Or a randon colored PT (because we two are too familiar with location-category, which makes bad testing).

Templates I'd like:

• RGB <---> H-S-V values calculation (both ways).

Because: when we pick colors, they may be construed in H-S-V, and otoh we might have colors in RGB.

RGB best be the 6-digit triplet; H-S-V can be °-%-% (?), and 3-parameters input? (or °-255-255 (more precise).

1. Black, 2. Wikilink blue

Also, optionally: ~four font colors (current SoM).

• I'd combine those into a complete set (10+1 categories defined & analysed). -DePiep (talk) 16:47, 10 August 2017 (UTC)[reply]

Useful templates

Let me relist the useful color analysis templates.

• From RGB (hex triplet) to HSV

Format: hex triplet can be/must be: #hhhhhh or #hhhhhh (e.g. from {{element color}}, this is to prevent the # creating numbered list in the template).

Format HSV tbd, could be a string °-%-% or °-1/255-1/255.

See {{RGBtoHSV.H}}, {{RGBtoHSV.S}}, {{RGBtoHSV.V}}. Do you need me to rework that to {{HEXtoHSV.H}} etc. or is what's been made okay as well?--R8R (talk) 16:51, 26 August 2017 (UTC)[reply]

I created {{RGBtoHSV.HSV}} and {{RGBparse}}, not sophisticated but working well in User:DePiep/PTCC/2013. -DePiep (talk) 16:56, 26 August 2017 (UTC)[reply]

• From HSV to RGB

Input HSV format tbd, 1 or 3 parameter values?, string as produced in previous template?

{{HSVtoHEX}}? Is there anything you need that this template does not address? (My PT color sandbox is one example of that template in use if you need one.)--R8R (talk) 15:22, 13 August 2017 (UTC)[reply]

Shows how off I am in this... -DePiep (talk) 15:31, 13 August 2017 (UTC)[reply]

• Input RGB, check contrast (W3C) with fontcolor (default=black, optional), return number & pass/fail

Also, will be used with fontcolor Wikilink blue (RGB=...), and SoM colors.

These are core templates, I'll combine them to describe & analyse any color set.

{{Color contrast}}. Good enough?--R8R (talk) 19:46, 26 August 2017 (UTC)[reply]

-DePiep (talk) 11:39, 13 August 2017 (UTC)[reply]

This whole template writing is such a bummer. I've got it and only then look closely and see there are these templates already. I have only myself to blame.--R8R (talk) 19:51, 26 August 2017 (UTC)[reply]

Very well. I'll do it as soon as I have time for Wiki.--R8R (talk) 15:22, 13 August 2017 (UTC)[reply]

I have no argument to speed you up — at all ;-) -DePiep (talk) 15:31, 13 August 2017 (UTC)[reply]

• R8R I've made additional templates. See User:DePiep/PTCC/newcolors#R8R-2016 ;-).

R8R -DePiep (talk) 00:38, 26 August 2017 (UTC)[reply]

Please take a look at my sandbox. I've just set up a color contrast check table in my sandbox. Possibly you'll find use of that yourself, so feel free if you want to.--R8R (talk) 19:28, 5 November 2017 (UTC)[reply]

The merged nonmetal version looks better to me, since the other one has all the greens starting to run into each other (important since H is next to those active metals). Note that this is not an argument to merge them, just an observation on the current schemes proposed. Double sharp (talk) 07:35, 6 November 2017 (UTC)[reply]

In fact, I am not proposing either of them at the moment. This thread contains some useful advice, which I have not followed or even taken into consideration; I just threw colors around so they're all good for the table. I am certainly not proposing the split nonmetal table because frankly, I have not even tried to make it look good. I have also not even tried to take predicted colors into consideration yet. However, I also think we should agree not to use different colors for different states of matter (for a good scientific reason: this is a periodic table of the elements, not of the simple substances). It could be we could even talk about aesthetics of this table then. And I, again, have not even checked this new color scheme against DePiep's suggestions. --R8R (talk) 08:28, 6 November 2017 (UTC)[reply]

@R8R and Double sharp:. That's an important table, and it shows what we are up against. Now I'm only talking not acting, but I'd subdivide the quest into subtopics like "fontcolors" (now SoM), "categories", "border" (now ocurrence), "background", "unknown status" (in multiple properties). And apart from contrast requirements, we could add colorblindness check (exponentionalise the possible conflicts...). AFAIK, colorblindness awareness says to not use certain colors together, and with 10+1 categories start using different shades. (I have a hardcopy of [1], did not find this issue yet on the net). -DePiep (talk) 09:49, 6 November 2017 (UTC)[reply]

Found this: Colorbrewer section 3, and [2]

New

Hi! Just wanted your opinion on a color scheme I've made: (look for the test table). I've made a monochrome table, made sure all categories are separable in the monochrome mode, and then added colors from the main table (with minor adjustments). This looks very promising to me.--R8R (talk) 13:31, 20 June 2018 (UTC)[reply]

R8R (was replying, then urgency - concept in my sandbox. The urgency was ... a replacement computer). Later more. DePiep

• R8R Your new proposal User:R8R/PT_search_for_colors#Test table (the 2nd one)? In that second PT, the noble gases are darker green, but not so in the contrast-checking table.

I do not understand your saying "monochrome" (=defined: 1 color only). Are they from a same-S&V in HSV (as it looks like in User:R8R/Template:element color-test? I assume that you found most different colors (Hues) as possible when keeping S&V 'teinte'? the same, in H-S-V.

(at User:DePiep/PTCC, for development, I have easy-fied the process, e.g. in User:DePiep/PTCC/newcolors#R8R-2017: enter color once. But that is for an other day).

• reply. Clearly we only need ten colors not eleven any more, good. You have picked them nicely from the hue circle. However, I don't think this is the way to go (fixed S-V values). Because the main job of these colors is to link a cell (or cell set) to the specific legend description. A reader must be able to connect a cell to a legend description (=category name). Using only same-teinte colors, it looks like this job fails.

I have diffuculty recognising the exact color in the PT and the legend (I know am slightly colorblind btw, as many people are; 5%?). It comes together in group 3, which is extremely mixed and so extremely confusing & difficult. Imagine you are an unexperienced PT-reader, looking at it for the first time. Could you connect the cells with the right category right away? Or, test it by making a color-shuffled and blind (=text-less) PT to switch of pre-knowledge, and try to recognise the colors. (The situation might truly be improved by making all colors darker equally, but that will surely add contrast issues; even when we would limit the fonts to black & wikilink-blue).

I think, to get this recognition better, we need to leave the single-teint route, and accept we have darker & lighter colors in there. I am exploring Cynthia Brewer's ColorBrewer, e.g. [3]. - DePiep (talk) 10:58, 21 June 2018 (UTC)[reply]

Perhaps I should explain the monochrome part in greater detail. I originally tried a monochrome table to see what it looks like, HSV 0-0.27-v (v=0.68, 0.76, 0.84, 0.92, 1). I found that it was possible to make a table with these five colors that would have all categories separable. Then I added hues (making it no longer monochrome) from my previous table (again, with small alterations). I figured the resulting table would be better in that the colors differ in not only in hues, but also in values. The colors do differ to me more profoundly. That was what excited me in the first place. I decided to lessen the value differences for various reasons (for instance, 0-0.27-0.68 was too dark) and now the values are 0.8, 0.85, 0.9, 0.95, 1.

No, I have no color perception deficiencies and I am able to connect every color from the legend to every cell easily. But speaking of color-blindness-friendliness. Do you happen to know what are the effects that simulate various color blindnesses? I've tried to look for it so I could emulate various color blindnesses but was unsuccessful in my search.

To summarize my feelings, I am ready to accept having to go for darker/lighter colors but I'd still like to try to write a good circular scheme as long as it does not prove impossible, which can only be determined by trial and error.--R8R (talk) 14:07, 21 June 2018 (UTC)[reply]

I get it, monochrome originals. Might be the squeezing from 0.68 to 0.80 (lowest) that reduced the basic effect (you used) a bit. About that number of five: I was thinking about identifying the colors that arre bordering in our PT, and at least try to use extremes for those (not neighbouring ones like yellow-orange; or 0.80/0.84 in your scheme.). And/or: maybe four could do, so that they can be more distanced from one another. That is: 0.8-1.0 with four points not five. One more thought: maybe your graph improves when we separate neighbouring hues (not red-orange bordering), abandoning the nice rainbow sequence... (Thoughts only so far).

re colorblind aware designing: Brewer spends some time on this in her book ([4] I have in print but not at hand... [5] is about that chapter. I want to look at [6]. ). The problem is that CB people cannot distinguish some color pairs (famously: red-green). She shows, in a smart 2D drawing, colors (areas) that should not be used (removing 40% of her 40? example colors!; they vary in hue and lightness). She also adds the rule "do not use colors that differ under 20% lightness" (or so). Since we need ten colors, that leaves us little free choices.

Maybe the PT has this usable advantage: the categories are in mostly in sequence left-to-right, as is the legend list below. So some colors are not near each other. MAybe we can use "bad" color pairs not near each other: say reddish for alkaline earth metals, and greenish in the p-block (for metalloids, PTM). - DePiep (talk) 14:58, 21 June 2018 (UTC)[reply]

Thanks for giving me a link to that color blindness simulator. I see now the task as I put it is very difficult. Probably not unsolvable, though. I'll keep on trying. Please take a look at the current version (for the time being, ignore SoM colors and occurrence frames): is this an acceptable solution or is it at least close? I can match each color in the legend to a certain category in the table with any color blindness simulation of the three activated. I can see the temptation to give up on the circular color scheme but I still think it is a big aesthetical gain, so I better try to keep it if that's possible. The PT really is different from a political map with the circular nature of its categories: AM--AEM--TM--PTM--metalloid--reactive nonmetal--NG--AM--- and this cycle goes on and on, whereas countries on a political map are one of a kind each and just need to be different.--R8R (talk) 17:53, 22 June 2018 (UTC)[reply]

OK. I see I am writing quite chaotic. It comes down to: TEN categories to distinguish is very much, and then also serving CB people adds an extra restriction. And this is categories only, before entering fontcolors meanings like for SoM (I am easily willing to drop fontcolor legends for this). DePiep (talk) 01:54, 23 June 2018 (UTC)[reply]

New, July 2018

Please see the first table now. Looks fine to me given the restrictions. All categories are distinguishable with your color blindness simulator activated; all color contrasts are currently above 4.5 (see table at the end of the page). What do you think of it?--R8R (talk) 10:09, 10 July 2018 (UTC)[reply]

Wow! I like the first one a lot. Sandbh (talk) 07:15, 11 July 2018 (UTC)[reply]

Me too! ^_^ Double sharp (talk) 03:35, 12 July 2018 (UTC)[reply]

I guess It looks like the nicest appearance so far. However, I want to make some checks, like on colorblindness (DB), when I have some more time. R8R, "your color blindness simulator activated" is that ther eye-icon in http://colorbrewer2.org? -DePiep (talk) 05:50, 12 July 2018 (UTC)[reply]

Thank you, everyone, it is nice to hear that. DePiep: No, I meant the program you linked, Color Oracle. I tried it with each color blindness simulation. By the way, when you do make your checks, would you share with me what these are so I could factor them in any future search for colors?--R8R (talk) 16:22, 12 July 2018 (UTC)[reply]

of course. It will require sound reasoning etc. In a few days more. -DePiep (talk)

I like the first one because the colours are consistently soft, there is a good balance of shades, and the transition from one colour to the next colour is smooth. And H nicely, but not too loudly, stands out from the alkali metals. Sandbh (talk) 00:41, 13 July 2018 (UTC)[reply]

Not good enough. It only looks nice for people like us: we know what to expect so we recognise. But. For a fresh person, this is not clear. For example, to check: what when these colors are in a micro PT? (ie with no text links). -DePiep (talk) 23:58, 21 July 2018 (UTC)[reply]

Currently, a proposal is finalised to change the NNNM's into one category: Reactive nonmetals (see Wikipedia_talk:WikiProject_Elements#Reclassifying_the_nonmetals). For the new category, a background color needs to be chosen. This section is about issues with that, many existing and some new.

Links

• User:DePiep/PTCC -- homepage in this research
• User:DePiep/PTCC/2013 -- 2013 color set overview
• User:DePiep/PTCC/2013 -- 2013update2018 (SoM changes) color set overview
• User:DePiep/PTCC/newcolors: testing contrasts for new colorset(s)

#NNNM-2018_(final_push)

#SoM_contrast

• {{Periodic table/sandbox}} -- new color(s) applied to basic PT, currently: NNNM=reactive nonmetals, green

{{Periodic table/blind1}} -- green, same, graphics only (no texts)

{{Periodic table/blind2}} -- yellow

• "NNNM" = non-noble nonmetals, as a blanket category name.
• "SoM" = state of matter, colors as used in fontcolor (green=liquid, red=gas)

-DePiep (talk) 12:04, 19 April 2018 (UTC)[reply]

Colorsets

Colorset 2013

See User:DePiep/PTCC/2013

Existing issues: Color contrast with fontcolor non-w3c compliant (not AAA or AA).

See #SoM_contrast, nine existing combinations are not conformant ("none").

Change 1 (April 2018)

Proposal: Change NNNM-2013 colors (green, yellow) into one (reactive nonmetals, green). See PT/sandbox.

User:DePiep/PTCC/newcolors

Issue: contrast with fontcolors worse: ten combinations are non conformant (Br=green added).

Change 1b variant yellow (April 2018)

Changing into some yellow not green: back to nine nonconformant situations (see table change as #1).

Discuss

• SoM fontcolors. R8R had good SoM fontcolors in 2016 (darker). Would they be an improvemment anyway already? Improve existing conformation list? Or can we find new SoM fontcolors that would improve the situation?
• Change more colors now? Should we change other bg colors too? especially the AM and LC reds could use an improvement
• Or should we go quick & dirty, i.e. yellow right away, for now? - DePiep (talk) 12:04, 19 April 2018 (UTC)[reply]

Fond these colors in User:R8R/Template:element color

<!-- PHASE (fontcolor) -->
| solid        = #000000
| liquid       = #0000cf<!-- blue! -->
| 2liquid      = #0000cb
| ga | gase    = #cf0000
| 2ga | 2gase  = #cb0000
| unknown | unknownphase = #646464

Notes: which of the 2 is used? And: blue fontcolor might not be distinguisbhable from wikilinks. R8R - DePiep (talk) 12:26, 19 April 2018 (UTC)[reply]

I used to work on two color sets at the same time, one reflecting the merge that is about to happen and one reflecting the current categories. The categories containing a 2 refer to the to-be-adopted category set.

I actually hope that this category change will reignite a full PT recovering. DePiep, would you be so kind and look at my latest color set and say if there is yet anything I need to work on?

Also, I wish we phase out states of matter. That is not a property of an element; that is a property of the simple substance formed by that element. Like we mark chlorine as a gas because elemental chlorine is one, but most people encounter chlorine as a solid (over a half of the common salt).--R8R (talk) 13:44, 19 April 2018 (UTC)[reply]

Or, since you seem interested in the issue, will you produce a color scheme of yours? I'm sure we all would love to see one if you provide it.--R8R (talk) 13:53, 19 April 2018 (UTC)[reply]

They are in the contrast-cheching tables btw. (see links 2013, 2018 above). When testing fontcolor too, the overview might be lost (hard to be systematic & keep overview).

Low hanging fruit: I discovered that if we use red #cb00000 not current #ff0000, already two bad contrasts are gone (from 2013 scheme). Will tweak a bit more.

For the rest: will reply later. Problem is: cannot change everything at once: too complicated to discuss. Goal 1: allow new category Reactive nonmetals to proceed (color issues should not delay). Probably needs & allows change in the SoM colors. But changing the big backgrounds: not this week (as I said before, should be OK wrt things like colorblindness, recognise from cell to legend so no similar colors, and contrasts; alas good that we loose one category shortly, 9 is easier than 10). - DePiep (talk) 14:31, 19 April 2018 (UTC)[reply]

Hello DePiep. I was wondering if it was not too much to ask you to draw me a graph like File:Aluminium - world production trend.svg, but for prices rather than production. I have a certain feeling that asking to draw such a graph would be a lot to ask for, so I would be very grateful if you could do it and of course, you could ask for a favor in return. If you could, I will explain in detail what exactly I want (in my opinion, nothing special) and where you could find the data.--R8R (talk) 12:41 am, 12 December 2018, Wednesday (28 days ago) (UTC+3)

"I will draw" he said famously. (will need time) he also said. -DePiep (talk) 1:13 am, 12 December 2018, Wednesday (28 days ago) (UTC+3)

Thank you very much. I would like a graph containing two lines: one for the nominal prices and one for the real prices that should have different colors. I envisioned dark gray/black for the nominal prices and red for the real prices, though you may choose differently. And that's essentially it.

Now as for data. I have a year-to-year set of data from 1900 here (find Aluminum and get the .xlsx file under the column Supply-Demand Statistics from there). I actually also wanted to include more data from before 1900 but I need to rethink what data is exactly worthy. Whatever is chosen, it won't need a dubbing in real prices. I will figure out what to use and then pass it to you.--R8R (talk) 3:22 am, 12 December 2018, Wednesday (28 days ago) (UTC+3)

R8R I've read the file (ds140aumi). Do I understand: "nominal prices" = $/t at the time, "real prices" = $₁₉₉₈/t? -DePiep (talk) 1:06 pm, 12 December 2018, Wednesday (27 days ago) (UTC+3)

Yes, you got that right.--R8R (talk) 3:24 pm, 12 December 2018, Wednesday (27 days ago) (UTC+3)

• R8R Here you are. I used wonderful c:SVG Chart. I used two colors, makes the lines stand out & recognsable (while crossing).

Todo

1. Add full data set (each year), not just 10-yrs (DePiep)
2. Stretch vertical (graph should be ~square) (DePiep)
3. Check all texts: Y-axis, X-axis, title, legends
4. In general, be inspired by these examples: commons:Category:Valid SVG created with Wikimedia SVG Chart

-DePiep (talk) 8:02 pm, 12 December 2018, Wednesday (27 days ago) (UTC+3)

You think it would be more instructive if the blue line were on a different scale (0-200 $/t), having its own scale on the righthand? (Can be done). Red line would be unchanged (and using lefthand axis). -DePiep (talk) 8:11 pm, 12 December 2018, Wednesday (27 days ago) (UTC+3)

Thank you very much. Also thank you for sharing this interesting tool you mentioned. Hopefully I'll be able to make my next graph on my own. I've got Inkscape on my computer but it is not very intuitively clear to me and since I don't really have that much need in using it (at the very best once in a few months, and all of these cases are for Wikipedia where I can ask for help), I haven't learned how to. For now with Inkscape, I can only do the most basic things like changing a color. Here is my magnum opus with it (where squares, and the red and blue arrows had already been created by the time I got to this).

I was a little worried that the graph didn't look very precise before I read your to do list. If that is yet to do done, everything is fine then.

As for the texts, here are the changes I'd prefer: I'd like the words "metric ton" instead of "ton" in the title of the graph and the vertical axis label ("ton" on its own is ambiguous: see ton) and "t" instead of "ton" in the legend (simply because it takes less horizontal space and is still correct). Also not yet sure how to deal with the dollar sign ("$" or "US$"? What about "98"---should it be "98US$"? Maybe the smart decision would be to mention in the title that the dollars are the U.S. dollars---something like "Aluminium, historical price per metric ton in USD" and have the plain "$" afterwards. Still need to think how to mention the 1998 dollars are from 1998. USGS uses "98$"; sort of makes given that the country of a dollar is always written also before the dollar sign: US$, A$, C$, NZ$, etc. Then again, they also spell it out and since our graph doesn't, this may look a little puzzling. "1998$" is clearer.)

No, I don't think we really need two different scales. I think that this long-term chart is supposed to give you a visual representation of the trends but not the exact values which would be hard to read anyway. I'll link the sources in the file description in case someone needs a look at the data.

I will probably have set up a table with various pre-1900 prices and costs I can find at Talk:History of aluminium by the end of this week and we can see from there how the graph could be expanded into the nineteenth century.--R8R (talk) 9:07 pm, 12 December 2018, Wednesday (27 days ago) (UTC+3)

• Replies & notes-to-self. Yes, a great tool for these graphs. I found it through the "production trend" example file you mentioned ;-). FYI, the source code is in talkpage commons:File_talk:Aluminium_-_historical_price_per_ton_(nominal,_real).svg (that is: my template input code, so look at the talkpage in edit mode). That's how it works. If you want to experiment & work with this graph, go ahead, but better not edit together (iow I can leave it to you, but I propose to work further on this now). There are a lot of parameters to squeeze him right, they need experimentation. The two data lists are the easiest ones!

And yes, happily no Inkscape needed here -- but for a masterpiece you can't do without it. Inkscape is my preferred tool too (until today...). BTW, I also do this (today too): paste the svg code in my notepad++ texteditor, save it on file, then choose menu "Run | Show in Firefox" which tests the svg right away. Even allows editing in-code fast (and tricky).

About the graph: I will process your suggestions, all reasonable. I found MOS:CURRENCY saying ~the same about use of $ symbol. For 1998-USD I will try "$₁₉₉₈" in the graph. It stays "aluminIum" in this then (as does the history article, except for company names etc).

I guess you can describe "real" and "nominal" cost in the caption. For me it was a discovery/study to get it.

If you have the pre-1900 prices (very interesting indeed), we can extend the data range in this one (and adjust axis settings etc).

And of course: what a wonderfuil graph. Shows that Al was more expensive than gold (1916!), as we were told.

Got work to do. - DePiep (talk) 10:45 pm, 12 December 2018, Wednesday (27 days ago) (UTC+3)

Aha, got it. Well, I'll be heading off to sleep now (so sorry if this reply is incomplete). How about I write you when I want to go edit it and then in no less than half an hour tell you when my editing session is over or leave it to you for now altogether if you don't think that's too rude of me? I'll fill my Wiki time with adding more stuff to the article.

I do get it that Inkscape is so cool---it wouldn't be so poplar otherwise even though it's free. I just need to learn how to use it (and I've seen loads of online courses) to actually use it, but then again, I don't have the need, it's always just little something for Wikipedia. If I were a graphical designer, though, I would've probably learned it ages ago.

I like explaining things but I think that explaining the difference between real and nominal prices is sort of off-topic in history of aluminium. I also think real versus nominal value (economics) which the article links to does a fairly decent job in explaining the concept. If it were, however, more closely related to the topic in hand, I probably would explain it.

(ec) Let me know when you want to start editing this graph. I will happily leave it, but cannot promise I can come back & then understand your discoveries and solutions and improvements. It's not about being rude, but about working impractical/inefective. See you tomorrow. -DePiep (talk) 12:04 am, 13 December 2018, Thursday (27 days ago) (UTC+3)

Just a quick note: this graph does not show that aluminum is more expensive than gold at any time. Its price approached that of silver back in the 1860s. In 1916, a troy ounce of gold cost about $20 per troy once (31 gram). That's $640,000 per metric ton. Aluminum did cost more than gold way back before Deville found a way to produce cheaper sodium, which happened in 1855 or 1856.--R8R (talk) 11:51 pm, 12 December 2018, Wednesday (27 days ago) (UTC+3)

Also, speaking of costs: I have not seen any proof that anyone actually bought or sold aluminum back then. It did cost more to make an ounce of aluminum than an ounce of gold. As for prices, I can't verify anybody could buy or anybody was willing to sell for money a piece of aluminum before 1855, so it could be there were no prices to speak about.--R8R (talk) 12:00 am, 13 December 2018, Thursday (27 days ago) (UTC+3)

My "gold" remarks were only frolicking, afterthoughts. I will take another look at texts and data as discussed. Do write here when you want to take this graph over. -DePiep (talk) 12:37 am, 13 December 2018, Thursday (27 days ago) (UTC+3)

I've given it some thought and I think, not in a while. So if you'd like to improve it, please feel free. For now, I want to work more on the text. I want to answer the questions I have listed at Talk:History of aluminium. Also, I presume after more additions there will be more vertical space; currently, on my 1600x900 laptop screen, there's not enough room for one more picture now but there probably will be later. Maybe the pre-electrolysis prices will require a graph of their own (if so, I should be able to make it myself; I think that space for two more pictures is also a possibility).

As for gold, there is no need in trying to excuse yourself. I rather think I need to clarify this moment in the article better. Maybe if a separate graph for pre-electrolysis prices is to be drawn, it may also include the prices of gold and silver for comparison. In case you're curious, aluminum cost about as much as silver already in the 1860s IIRC.--R8R (talk) 11:39 am, 13 December 2018, Thursday (26 days ago) (UTC+3)

OK. At this moment I'm preparing the full data lists. -DePiep (talk) 11:43 am, 13 December 2018, Thursday (26 days ago) (UTC+3)

• Uploaded second version. All data in there, adjusted texts. Could not manage to stretch vertical (into more square graph). Input is in c:File talk as required, for future edits.

I'll leave it here. You can always ask here to have me look & experiment with more details etc., or edit yourself. Have a nice edt. -DePiep (talk) 12:40 pm, 13 December 2018, Thursday (26 days ago) (UTC+3)

Thank you very much. I'll try to incorporate this graph into the article when I reach my laptop. Generally, I'll take it from here. I'll see if I can make it more square-like and improve the file description.--R8R (talk) 4:10 pm, 13 December 2018, Thursday (26 days ago) (UTC+3)

By the way, I just reconsidered and I think that explaining the difference between nominal prices and real prices may actually be a good idea if that is done in a note. One of the main reasons why I didn't want to do this was that I've been familiar with the concept since my early teen years and I sort of expected everyone to be familiar with it as well, so explaining this would be pretty much explaining the obvious. However, it occurred to me that even though I was familiar with it, there is no fundamental reason why everyone should be---this isn't taught in schools or talked a lot about on TV or in the Internet, for instance; after all, you said you weren't familiar with the concept---so yeah, it may be a good idea. Notes are perfect for such explanations. Maybe this could even be done in a simpler manner: "Nominal and real prices for aluminium from 1900 to 2015. The nominal prices (i.e., the prices customers saw at the time) are given in blue while the real prices (recalculated by ignoring the inflation the currency experienced so that the money had the same purchasing power throughout the years, here standardized to that of the year 1998) are given in red"; how's that sound?--R8R (talk) 9:53 pm, 13 December 2018, Thursday (26 days ago) (UTC+3)

Adding the note is good (and that cannot be done in the graph for sure). Could be a footnote. Your text here is a bit long. maybe like: "nominal price = price as paid at the time ("price in 1910: $492 then"). Real price = $ value recalculated to 1998-$ worth ("price in 1910: 8600 in $(1998)"). Real prices make prices comparable." -DePiep (talk) 10:52 pm, 13 December 2018, Thursday (26 days ago) (UTC+3)

Hello. I've tried to spend some time changing the graph (without really knowing what I was doing at first, it was more like, "let me change this and see what happens"). Eventually, I figured what does what, expect I don't understand one thing. On line 470, you have, transform="scale(1, -3). If I change that to transform="scale(1, -1), the lines are shrinked vertically and this makes perfect sense, I get it. What I don't get is why the line that has been stretched vertically by a factor of 3 looks fine and the seemingly untouched line actually appears very flat. Why is that?--R8R (talk) 3:48 am, 20 December 2018, Thursday (20 days ago) (UTC+3)

Will take a look later on. -DePiep (talk) 3:52 am, 20 December 2018, Thursday (20 days ago) (UTC+3)

re R8R.

First, about the creating technique. I did not write svg code, nor would I manipulate it in this case. The work happens at commons: say in commons:DePiep/SVG Chart. In there I put a regular template called commons:Template:SVG Chart. Then I write input in the template parameters (see page in editmode). When saving, the template creates svg code (as the saved page shows). That code I copy/paste in a notebook (text handling program), and save it in a file like "Some graphic.svg". That file can be uploadded to WP (and inspected directly in browser).

The template input for File:Aluminium - historical price is in its talkpage: commons:File talk:Aluminium - historical price per ton (nominal, real).svg. Take a look at it in editmode (=template input).

About the scaling. I have not tried your experiment (yet; not directly in svg). I do know this about scaling in this template:

• The SGC Chart makes a square grid (not rectangular). That is: the point (1, 1) makes a square with (0, 0). This way, the aluminum graph would be vertical: 0-20 = 20 units ($20k), horizontal: 1900-2020 - 120 units (years). Built in squares, the graph's high:wide is 1:6 (a wide landscape rectangle).
• Then I added |GraphStretchHeight=300 (scale Y-axis 300%, the max). Now its reach is "0-60", and a 1:2 rectangle results, as the alunminium file shows.

That's how far I have come. I did not make more experiments with the scale or other manipulations.

Clear enough? -DePiep (talk) 00:53, 14 January 2019 (UTC)[reply]

R8R was this helpful? The tech manual part is big (but rewarding IMO). Tell -DePiep (talk) 22:53, 20 January 2019 (UTC)[reply]

Sorry for a late response. As you can see in my Contributions, for example, I've been busy lately and not really active within Wikipedia in general, so I wanted to delay reading whatever you had for me to until I have enough spare time to act upon reading.

It seems to me that GraphStretchHeight is just what I need to solve my problem. However, I don't understand where it is present in your file exactly? I can't find that in c:File_talk:Aluminium_-_historical_price_per_ton_(nominal,_real).svg.--R8R (talk) 10:07, 21 January 2019 (UTC)[reply]

I don't mind, it is for you to use.

Open the file in edit mode [7]. It has parameter input |GraphStretchHeight=300 (300% = hte max per documentation). -DePiep (talk) 10:51, 21 January 2019 (UTC)[reply]

Thank you very much. I think I'll handle it from here.--R8R (talk) 11:51, 21 January 2019 (UTC)[reply]

Having given you grief before, I have to say I really like the way you've set out your recent requests. They're so straightforward to deal with. Thanks, Cabayi (talk) 21:34, 11 January 2019 (UTC)[reply]

Thank you!!! I do not remember a specific grief (I do not associate anything like that with your username; happily so). Now, I am not a TE any more, so I am invited to convince admins/TE's like you. Makes me a better-talking editor. Again: thank you for this post. Have a nice edit. -DePiep (talk) 21:43, 11 January 2019 (UTC)[reply]

Hi, DePiep! As near as I can tell from the page history, you are the editor who added the following text to the {{Convert}} template documentation under "Default rounding":

   "If neither the desired precision nor the desired number of significant figures is specified, the conversion will be rounded either to precision comparable to that of the input value (the number of digits after the decimal point—or the negative of the number of non-significant zeroes before the point—is increased by one if the conversion is a multiplication by a number between 0.02 and 0.2, remains the same if the factor is between 0.2 and 2, is decreased by 1 if it is between 2 and 20, and so on) or to two significant figures, whichever is more precise. An exception to this is temperature, wherein the conversion will be rounded either to precision comparable to that of the input value or to that which would give three significant figures when expressed in kelvins, whichever is more precise."

I have read over this paragraph 4 or 5 times now, and still can't make sense of it (the em dashes are part of what is throwing me, along with how they are being used along with commas to indicate subsets of information about the template). I am not a mathematician, just an editor, but am wondering if you would be willing to rephrase that so that other editors like me can figure out what it means! It appears to be grammatically correct— I am not trying to correct you! I am just saying, "I don't understand it the way it is written". I suspect I am not the first person with this problem. I tried fixing it by rewriting it myself, but got lost in the structure. Any chance you would consider it? Thanks! A loose noose (talk) 00:58, 12 January 2019 (UTC)[reply]

Well, it looks like you've done some new editing there, but you haven't yet taken a shot at clarifying this paragraph (?). You know what you mean here better than anyone else, and no one is better qualified to tackle this. But maybe you don't think it's really a problem! Or maybe you are going to get to it soon, and I should be more patient. I will keep checking back. A loose noose (talk) 08:55, 13 January 2019 (UTC)[reply]

I asked the wider community here. As I wrote, I think I am a bit blinded. -DePiep (talk) 11:39, 13 January 2019 (UTC)[reply]

Hi DePiep, it's been a while since the Infobox school merge discussion - really glad it was a success. I'm sure you remember the after-merge discussion which we had started but left it for a while, we're about to start it and I've made a few changes and added further things. Just wanted to ask if you are interested in continuing the discussion, please let me know, thank you Steven (Editor) (talk) 20:22, 15 January 2019 (UTC)[reply]

Steven (Editor) Thanks for inviting me. However, I perefer to decline the invitation. Reason is the experience after we started the UK school merge last October, then after some weeks someone else came by, did not engage in talking, hi-jacked, stole and wrecked the merge process without understanding what they did wrong (archive, [8]). I don't see the pleasure of once more spend energy onto such a prospect. -DePiep (talk) 12:55, 16 January 2019 (UTC)[reply]

You reverted my edit at the start of Isotopes of Nitrogen. The value for N-10 in the text doesn’t match the value in the table. Newystats (talk) 23:13, 1 February 2019 (UTC)[reply]

re Newystats. I reverted [9] because it was not clarified or sourced. GF all around. What are other editors' opinions? -DePiep (talk) 23:19, 1 February 2019 (UTC)[reply]

Template:IPA audio filename has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Gonnym (talk) 08:31, 6 February 2019 (UTC)[reply]

Hey, I noticed you marked all pages in Category:Periodic table deprecated border templates as deprecated. Two questions which would save me time investigating this. Is {{Element color}}} a complete replacement for the entire templates listed? And why was Template:Element frame deleted while the subpages not? --Gonnym (talk) 12:39, 6 February 2019 (UTC)[reply]

A1: Yes, {{Element color}} is a complete replacement for all templates in that category. Could be five years or more this way. I've kept them because I was not sure if they were used in some secondary, useful page (like in ns: Wikipedia). Expect outdated content too.

(So since you are working at this, I'd say check once more for mainspace usage, delete them, and let those archive pages become redlinked. If an affected page would be important, we can recreate it using the modern template).

A2: Template:Element frame was deleted because of someone else's TfD (not checked for subpages back then). Unless you see something strange in the deleted page (using admin rights), this template fits the category you mentioned just as well. HTH. -DePiep (talk) 12:53, 6 February 2019 (UTC)[reply]

Note: same for Template:Periodic tables key: deprecated >5years, unused mainspace, replaced. Candidate speedy. -DePiep (talk) 13:00, 6 February 2019 (UTC)[reply]

If you want to, I dare putting them up for speedy db-g6 or so. -DePiep (talk) 13:16, 6 February 2019 (UTC)[reply]

Thanks for the info! --Gonnym (talk) 13:17, 6 February 2019 (UTC)[reply]

Are all the templates in Category:Periodic table deprecated color templates also fit for deletion? --Gonnym (talk) 12:53, 17 February 2019 (UTC)[reply]

I don't have a position on whether this is useful, and I have no opposition if you or others think so. However, this is offloading of a large large amount of content contributed by many editors and there is no attribution chain in the history or talkpage of the new location for it (by history, you are taking credit for writing all of it yourself...obviously not what you intend). See WP:PROSPLIT for the proper process. Since this is actually the vast majority of the whole article, and much of the edit history is to the table (the content you want in the template) I wonder if it would be better to move the whole article to the template and then split back the prose to the article name? To my eye, that might keep more of the history intact at a single pagename. DMacks (talk) 03:01, 14 February 2019 (UTC)[reply]

I have not thought about this attribution aspect but you do have a big point. Will take care of this later on. -DePiep (talk) 03:05, 14 February 2019 (UTC)[reply]

Let me know if you need "admin" help with any of it. DMacks (talk) 03:17, 14 February 2019 (UTC)[reply]

 :-) :-) I was looking at this at this moment, esp re merging histories. Will be OK. -DePiep (talk) 03:19, 14 February 2019 (UTC)[reply]

• Well, since you are an admin: please perform as you propose. Like, imo:

1. Kill the (recent) template
2. Move old article page (history=attribution!) to that template page
3. Recreate article page, use template transclusion (as is done today)
4. Ping me, so I can redo recent edits (manually; I know what I did today)

-DePiep (talk) 03:27, 14 February 2019 (UTC)[reply]

All done. I moved the article to the template, made the article transclude the template, moved the content from the template that surrounded the table itself back to the article, and tagged everything for history attribution. Let me know if you need more help (any history of the now-deleted old Template or its doc/?). Looking forward to...whatever use this will have. DMacks (talk) 04:56, 14 February 2019 (UTC)[reply]

All fine, thanks. -DePiep (talk) 08:36, 14 February 2019 (UTC)[reply]

To accommodate readers, for ease of reading, the quote is now in a sidebox, and this allows the main text to be simplified. Qexigator (talk) 18:45, 15 February 2019 (UTC)[reply]

I will revert. This is not what we call 'consensus'. -DePiep (talk) 21:22, 15 February 2019 (UTC)[reply]

@Qexigator: Cannot believe my eyes. Cannot believe you did this. The section you left behind was an illegible chaos. I repaired some of it. One more edit this way and yoyu'll be up for ANI or whatever. And to be clear: did you have a convincing point, you had no need to go to my talkpage. Why did you post here at all? WP:CONSENSUS. -DePiep (talk) 21:22, 15 February 2019 (UTC)[reply]

Nice trick you pulled out: disrupt the section massively with that side-quote (I didn't even know that was possible or an idea at all), to distract me & us all from the grand chaos you gaslighted elsewhere in there. It will remind me that I have to revert more disruptive and non-consensual edits. -DePiep (talk) 21:44, 15 February 2019 (UTC)[reply]

Hey, not sure if you saw my previous question on the topic, but are all pages in Category:Periodic table deprecated color templates fit for deletion? --Gonnym (talk) 09:24, 25 February 2019 (UTC)[reply]

re Gonnym: yes, all are fit for deletion.

Notes: I checked a dozen (out of 61) for being used on mainspace: none (so that's good). For most of them, there are no replacements available (all modern ones use {{Element color}}, but not one-on-one). Also, their core legend function (legend color) may well be outdated = useless today. At first glace, I see no objection to subst:'ing where used (I leave that to the TfD processing; no opinion here); otherwise redlinks are created.

There are also incoming redirects (Template:Element color/7). I suppose these will be deleted by bot/TfD processing (good).

However, some subpages in this Prefix list are live. Keeps are: /sandbox, /overview, /secondary and their subpages (incomplete list here). I'll keep an aye on those. -DePiep (talk) 09:48, 26 February 2019 (UTC)[reply]

I noticed a few transcluded at Template:Periodic table (discovery periods, compact), such as Template:Element color/1800-1849. Is that table still used? --Gonnym (talk) 10:16, 26 February 2019 (UTC)[reply]

These templates are all unused. Are they subst templates or just stuff that was replaced and not needed anymore?

• Template:Infobox element/symbol-to--(blank)
• Template:Infobox element/symbol-to--(blank-group)
• Template:Infobox element/symbol-to-electron-configuration/electron-configuration
• Template:Infobox element/symbol-to-image/fairuse

If they are not needed, could you speedy delete (G7) them as you are the only editor and it would save time. --Gonnym (talk) 08:12, 1 March 2019 (UTC)[reply]

Gonnym I have speedyéd the last two. First two are relevant & useful (blank templates to fill). -DePiep (talk) 15:43, 1 March 2019 (UTC)[reply]

Hi, please could you modify {{NNDC}} to fix the partial |accessdate= as all of the articles using it are now showing a date error. Thanks. Keith D (talk) 20:07, 3 March 2019 (UTC)[reply]

I tried to already, but ould not find the error cause [10]. Will take an other look. -DePiep (talk) 20:09, 3 March 2019 (UTC)[reply]

|accessdate= needs to be a full date including day, month and year. Keith D (talk) 22:44, 3 March 2019 (UTC)[reply]

The error is gone, right? -DePiep (talk) 23:47, 3 March 2019 (UTC)[reply]

Template:When in sandbox has been nominated for merging with Template:Sandbox other. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Thank you. {{3x|p}}ery (talk) 01:23, 4 March 2019 (UTC)[reply]

On my display (and using my eyes) it is difficult to see the color of the font used for the atomic number (indicating the state of matter). If the font was bold, the color of the font would be easier to see. The number is on a line by itself in the cell, so the extra width of the bold font would not (apparently) effect anything else, and it would improve WP:ACCESSIBILITY. Sparkie82 (t•c) 17:02, 5 March 2019 (UTC)[reply]

Sparkie82, you are referring to the font colors in the {{Periodic table}}s then. You are right, these colors are (too) hard to recognise, also wrt the legend. However, the things to keep in main are multifold and often contradicting So far we have not found an easy solution. Maybe bolding is one, indeed.

Some background. When checking for ACCESSABILITY of webcolors (that is, readability in this case indeed), we use the w3c guideline to calculate contrast ({{Color contrast ratio}}, [11]). For bigger fonts it gives a better result (it signals a better readability). It says nothing about bold fonts, but it is worth a good look.

In this situation we have these nine+grey background colors for the categories. Finding nine good background colors is a difficult job by itself: they should have with good readability for simple black fontcolor (and blue wikilink color), they must be distinguished, etc. At the moment, some are not OK such as the dark red alkali metals. Once we have these nine, we can look for the fontcolors (now red and green). As you can imagine, the degrees of freedom are few.

Actually, when we changed the set last April 2018, we darkened the red and green fonts a bit for better contrast. Consequence: they do not stand out any more, as the brighter red and green did. (I think this is what you see: though a better w3c contrast it is).

So this is in play. Now, I' will write a note to myself (and keep in mind) that this number bolding is worth investigating, possibly i.c.w. enlarging. Thank you for your report. -DePiep (talk) 06:45, 7 March 2019 (UTC)[reply]

I really am. It pains me to do so. Yet I'm afraid I have been left with no other choice.

Feel free to take part.--R8R (talk) 17:23, 10 March 2019 (UTC)[reply]

No you don't. Because: you did it. You did have a choice. -DePiep (talk) 20:44, 10 March 2019 (UTC)[reply]

The good news is: I don't see WP:BF. Must be something else. You won that lousy talk, still you see a problem? Beyond me now. -DePiep (talk) 21:06, 10 March 2019 (UTC)[reply]

Oh and please do not ever go to someone this way while saying "Feel free to ...". To this I say: fuck off. This does not give me "freedom to ..", it is forcing me to spend time on whatever accusation. It is you doesn't let me "Free to ...". -DePiep (talk) 23:20, 10 March 2019 (UTC)[reply]

Activity there has been died down for a while. Do you want to try to resume discussion again? Care to differ or discuss with me? The N^th User 16:39, 13 March 2019 (UTC)[reply]

Mmm. Takes a lot of smart thinking time. Do we know the next goal? And can we build that? When I left, I was not happy/convinced about the [interval] issues. Also, other topics are in play. I'll have a good sleep over it. -DePiep (talk) 16:52, 13 March 2019 (UTC)[reply]

There are various bugs that I'd like to have fixed. I'm thinking that we should start with the rounding error for fluorine, aluminum, manganese, iodine, lanthanum, gold, and uranium described in this section, as that's probably just a floating point error solvable by subtracting an extremely small quantity from usquare, it's best to start out with something relatively simple before tackling the more complicated stuff. Tell me when you're ready to start problem-solving. Care to differ or discuss with me? The N^th User 17:38, 13 March 2019 (UTC)[reply]

It's not about bugs. It's about: we must handle three value forms [interval], (uncertainty), -most stable isotope-. For all of these we must have the complete calculation form (algorithm). That is Possolo (2018) to me. If we know these, we can program the template -- only then.

Also, this is a distraction subject for me (because we don't know the target). I prefer to reduce time for this one. Lots of other topics (re periodic table) are waiting. (This puzzle is too complicated for me and therefor frustrating, because a) we don't know the algorithm, b) it must be in Lua).)

To be clear: current live form, with maxc number of decimals you introduced, is best so far. -DePiep (talk) 20:17, 13 March 2019 (UTC)[reply]

Should I work on it by myself then let you test it when I think that it's completely ready, or do you think that I would be able to help with what you're doing concerning the periodic table? I want to be able to work on something and be useful. Care to differ or discuss with me? The N^th User 20:44, 13 March 2019 (UTC)[reply]

you can ping me any time for questions or a check request, sure, OK. I WP:OWN the topic of Standard atomic weight ;-)

(first suggestion: remove this test-for-bad-input [12]: useless in development. Don't spend time on this.)

My points are, again: we cannot program software if we don't know the algorithms. So first source & dscribe the (three) algorithms. For me, that would be CIAAW sources.

After that, ask peolple at WP:LUA to program the module. They can (just put the right question / see prev point).

I myself do not have the time or interest to dive into this much more. The algorithmsms are missing. I can not and will not scrutinise the latest developments in CMM. I will not suggest code improvements, or set up tests.

Have a nice edit, -DePiep (talk) 21:07, 13 March 2019 (UTC)[reply]

re first suggestion: Done.

re sourcing algorithms: I'll put the source for using the Pythagorean sums in a comment, but I think that the logic behind the interval mode is straightforward enough to not require a source.

re LUA: I will respond to that in Template_talk:Chem_molar_mass#Future_development_(March_2019) to prevent a split. (I'm responding to the other questions here because you didn't ask them there.)

re myself: That's okay. However, is it okay if I ask you to help test it once I think it's finished? Care to differ or discuss with me? The N^th User 21:57, 13 March 2019 (UTC)[reply]

Yes, do ping me when you have a question! But I will unfollow our CMM development pages. Sort of heath thing: don't make myself overload with details. To be clear: that was a great edit process we did! -DePiep (talk) 22:04, 13 March 2019 (UTC)[reply]

I think that I need help with the rounding. Specifically, there are cases like Fluorine: 18.9984031630(60) g·mol−1 (debug:usquare=3.6E-17; u=6.0E-9; smart_round=9.2218487496164); value=18.998403163;unrounded_uncertainty_digit=6, Potassium: 39.09830(10) g·mol−1 (debug:usquare=1.0E-8; u=0.0001; smart_round=5); value=39.0983;unrounded_uncertainty_digit=1, and Phosphorus: 30.9737619980(50) g·mol−1 (debug:usquare=2.5E-17; u=5.0E-9; smart_round=9.301029995664); value=30.973761998;unrounded_uncertainty_digit=5 where the number and uncertainty each have a zero at the end even though this shouldn't happen when the uncertainty has only one nonzero digit (i.e. when the coefficient would be an integer if the uncertainty were expressed in scientific notation). I believe that this edit is what caused it; I added code to display an extra digit if and only if the unrounded uncertainty digit (the coefficient if the uncertainty were expressed in scientific notation) were not an integer, which I calculated based on ceil(unrounded uncertainty digit) ≠ unrounded uncertainty digit (although I have since changed it to unrounded uncertainty digit mod 1 ≠ 0). Can you figure out why the template is doing this? Care to differ or discuss with me? The N^th User 00:15, 16 March 2019 (UTC)[reply]

I was able to fix it with this edit. Now the only bug that I know if is in User:The Nth User/Molar mass test/testtable, where every value displays as an error starting at molybdenum–rhodium, but I think that that is a problem with the sheer length of the table, not the template, because other fields, like element stop working, the table itself gains extra columns, and in User:The Nth User/Molar mass test/testcases, the testcases with heavy elements, like cesium auride, work just fine. Can you find any bugs, or is the template ready for submitting to the module-programmers? Care to differ or discuss with me? The N^th User 01:26, 1 April 2019 (UTC)[reply]

Yes, the errors appear because the page is too large (to many function calls). The page is categorised Category:Pages containing omitted template arguments. Also, when in PReview, at the bottom there is the Parser overview, showing that some key numbers are at their max. Finally, if you remove the first 40 rows, the error appears at element 80 (that is, again around the 40th row). I have not looked for other bugs. -DePiep (talk) 07:02, 1 April 2019 (UTC)[reply]

Thanks for letting me know what's causing the problem. I'll see if there are any parser functions that I can replace with templates to decrease the call number, but I doubt that it's important as the template probably won't be used forty or so times on any article. Care to differ or discuss with me? The N^th User 01:48, 2 April 2019 (UTC)[reply]

I think that we're ready to go forwards. At User:The Nth User/Molar mass test/testcases, everything is working perfectly except for the extra zero yttrium, which I neither think I will be able to solve nor think is a significant problem because there is an extra zero in both the value and the uncertainty. What do you think? Care to differ or discuss with me? The N^th User 02:32, 5 April 2019 (UTC)[reply]

The yttrium case I cannot explain (beacues I did not dive intop the recent calcualtion setup). I can assume, as you do, that the extra two zero's indeed describe exactly the same uncertainty situation (same sigma!). I must be honest: me giving green light is not useful, because I did not check the setup so my voince has no weight. (I did not check whether new calculation is more exact and better following the prescription). Altghough I can state that you are working sincerely.

All I can advise is (first) copy/paste your userpages to their {{Chem molar mass}} /sandbox equivalent, and make it work ({{Chem molar mass/sandbox}}, {{Chem molar mass/format/sandbox}}, etc. Then (second) do all the tough tests, perferably in regular {{Chem molar mass/testcases}}. At least do check all single elements (evading the parser errors, so use three pages?), and test the compound masses mantioned in the Possolo paper (CO₂ etc.). When you are fine, (third) go to the talkpage and propose the change. Invite smart people (those working with molar mass calculations!). If you can convince them, you safe! Might take a lot of convincing power though, but it is the royal route. Otherwise you could propose it (the sandboxes) as a "improvement, well tested" (protected edit request) without discussion - tricky. -DePiep (talk) 16:00, 5 April 2019 (UTC)[reply]

I copied and pasted them in, but now a bunch of the testcases don't work, and I'm getting this error message: Warning: This page contains at least one template argument with an expansion size exceeding the technical limit. All such arguments have been omitted. I have no idea why I'm getting it because I didn't get it at User:The Nth User/Molar mass test/testcases. Care to differ or discuss with me? The N^th User 20:49, 5 April 2019 (UTC)[reply]

• I added CO2 to /testcases: [13]. Note the blank parameters |charge=, |round= (and check the tesresults). Removing those parameters gave a test different result [14]! (no errors!). IOW: those blank input matter. -DePiep (talk) 22:08, 5 April 2019 (UTC)[reply]

I noticed a problem: When the rounding is manually specified to be less than the smart round, the uncertainty is not adjusted accordingly. For example, see Template:Chem_molar_mass/testcases#Charge_and_sortable. I'll try to fix it. Care to differ or discuss with me? The N^th User 22:44, 5 April 2019 (UTC)[reply]

Please don't bother me with detials, can't read them. I already said I am not interested.(NO bad feelings). (useless & unhelpful post) -DePiep (talk) 23:24, 5 April 2019 (UTC)[reply]

Sandbox

So the sandbox set is: (2019-04-05):

• Template:Chem molar mass(edit talk links history)
• Chem molar mass/sandbox (edit · t · history · diff · links · /test · Source · e · t · hist · links · /subpages · /doc · /doc edit)
• Chem molar mass/format/sandbox (edit · t · history · diff · links · /test · Source · e · t · hist · links · /subpages · /doc · /doc edit)
• {{Chem molar mass/testcases}}

User:The Nth User/Molar mass test

User:The Nth User/Molar mass test/format

User:The Nth User/Molar mass test/testcases

I am confused by your edit summary in connection with this reversion. You wrote that "this should be solved in the article not here", but there is no article on the adjective, Christian. It is a disambiguation page, per consensus following a discussion on the term. As with other disambiguation pages, it should not be linked from any template. If you intend to link to the disambiguation page, however, the link must follow WP:INTDABLINK (this is policy). bd2412 T 15:38, 27 March 2019 (UTC)[reply]

First of all, it is a testpage and so even improbable, wrong or disputable options may be (should be) tested. Second, the subtemplates involved are under development, nothing is live. So it may be very confusing to have multiple simultaneous editing. IOW, in general one is supposed to go to the talkpage, not interrupting an editing process that is clearly not for publication yet. Is what I am asking now in this situation.

Now about the input option being a DAB page. The whole affiliation-to-id setup is to catch more input options for |religious_affiliation=. (Category:Infobox religious building with unknown affiliation (2,309); actually 1500 but alas). That is: recognise the religion entered. Then use that secondary, for coloring etcetera.

So if an editor enters |religious_affiliation=[[Christian]], for this purpose that is OK and better be accepted & recognised (so we use the right indicative bg color). The input also shows literally, i.e. as a wikilink, sure to a DAB page in this case. If that is a problem, this should be corrected in the church article itself (using the infobox), not the DAB page (is what I meant to say: "fix it in the article"). Anyway this is not a reason for the id-to-color process to declare an error. "Christian" is a correct affiliation.

On top of this: nothing wrong if the article links to this DAB page. Because Christianity indeed has many subvariants, so there may be a need to disambiguate -- even for the reader(s) not the editor. So ending up on that DAB page is helpful for starters. HTH -DePiep (talk) 15:56, 27 March 2019 (UTC)[reply]

Hi, I noticed that you have generated article lists for use with the recent changes for WikiProject Pharmacology and was wondering how the lists are generated. I am looking for a way to do this for other projects. Thanks. Keith D (talk) 01:46, 29 March 2019 (UTC)[reply]

Keith D Sorry I am late in responding. Will reply these days. -DePiep (talk) 17:25, 31 March 2019 (UTC)[reply]

Keith D I have updated one list page Wikipedia:WikiProject Pharmacology/Lists of pages/Pharmacology articles: Revision history. The process is described at Template:Recent_changes_in_Pharmacology#List updates. If anything is unclear, pls do contact again. -DePiep (talk) 15:07, 28 April 2019 (UTC)[reply]

Many thanks for the information. Keith D (talk) 19:52, 28 April 2019 (UTC)[reply]

Category:Hatnote templates documentation, which you created, has been nominated for possible deletion, merging, or renaming. A discussion is taking place to decide whether this proposal complies with the categorization guidelines. If you would like to participate in the discussion, you are invited to add your comments at the category's entry on the categories for discussion page. Thank you. DannyS712 (talk) 07:12, 11 April 2019 (UTC)[reply]

Module:Kill markers has been nominated for merging with Module:Unstrip. You are invited to comment on the discussion at the module's entry on the Templates for discussion page. Thank you. * Pppery * _{has returned} 20:27, 16 April 2019 (UTC)[reply]

Discussion has been inactive for the past eight days at Template talk:Chem molar mass, and I want to start it up again. I know that you already have plenty else on your plate, but we're the only two Wikipedians working on it, and I'm not sure how to go from where we are now. (Maybe reaching out to other editors who might be interested could be in order.) For the rounding, I think that if someone manually specifies the number of decimal places to greater than what is specified by the uncertainty, this should be allowed, but the number of digits in the uncertainty should be increased accordingly. This is better than people thinking the template is broken when it doesn't display the number of digits that they specified. Also, I've noticed that repeated calculations have been accumulating at Template:Chem molar mass/format/sandbox; maybe we should split the work into two templates so we can do each repeated calculation once in the first template then pass it into the second template as a parameter. Using parameters with short, descriptive names should also make the code more readable than long strings of parser functions whose function isn't immediately obvious. Care to differ or discuss with me? The N^th User 16:46, 28 April 2019 (UTC)[reply]

I need to think about engaging. Re "For the rounding, ...": "This is better than people thinking ..." -- better not IMO. Every person engaging in uncertainty, should know that one cannot make data more precise just by choosing a higher number of decimals here. The documentation should say: "The max number of decimals cannot be enlarged" or something like that. -DePiep (talk) 16:51, 28 April 2019 (UTC)[reply]

Idea of split (to prevent repetition) is good idea. The second template should be a subtemplate I think (not visible to article editors). -DePiep (talk) 17:01, 28 April 2019 (UTC)[reply]

Must say, again: these complicated calculations better be done by Lua, not wikicode. -DePiep (talk) 18:25, 28 April 2019 (UTC)[reply]

re rounding: While I agree that every person should know about uncertainty, I don't think that that's the reality. I honestly didn't know what the parentheses meant until I started working on this.

re split: I'll start working on it right away. I'll probably send one to Template:Chem molar mass/sandbox/calculations.

re Lua: I agree once we're done, but I think that it's better to get this working with templates before going to the Lua coders so the Lua coders don't have to experiment and troubleshoot. Care to differ or discuss with me? The N^th User 21:45, 28 April 2019 (UTC)[reply]

re re rounding: not our problem. They know, they should know or theyt can read the /doc. Really, don't spend time on this. -DePiep (talk) 21:51, 28 April 2019 (UTC)[reply]

re*2 split: I ended up creating a pipeline of templates, and I'm done now, but there are errors. I'll see if I can work them out. Care to differ or discuss with me? The N^th User 01:27, 29 April 2019 (UTC)[reply]

I am far too busy to waste my time on you at WP:ANEW over such a nonsense edit, but be sure, I'll find the time somehow. Andy Dingley (talk) 21:08, 28 April 2019 (UTC)[reply]

You obviously did not read my 1st editsummary. Then you went wild? What is wrong with "all or none"? -DePiep (talk) 21:15, 28 April 2019 (UTC)[reply]

They were all there, until you started deleting half of them. Andy Dingley (talk) 21:20, 28 April 2019 (UTC)[reply]

You better behave. -DePiep (talk) 21:27, 28 April 2019 (UTC)[reply]

You better behave better. Depending on your response, I might report you for trespassing WP:3RR. And BF. -DePiep (talk) 22:04, 28 April 2019 (UTC)[reply]

There is currently a discussion at Wikipedia:Administrators' noticeboard/Incidents regarding an issue with which you may have been involved. Andy Dingley (talk) 22:11, 28 April 2019 (UTC)[reply]

@MSGJ: How should I find another editor to work with on Template:Chem molar mass/sandbox while DePiep is blocked? There's something wrong with the template pipeline that I set up, and I have no idea what. Care to differ or discuss with me? The N^th User 00:21, 2 May 2019 (UTC)[reply]

You could ask for help at WP:VPT — Martin (MSGJ · talk) 08:11, 2 May 2019 (UTC)[reply]

Thank you. I have just made a new section there about it. Care to differ or discuss with me? The N^th User 20:58, 4 May 2019 (UTC)[reply]

• [15]

Really and sincerely, MSGJ, could you clarify (with diffs preferably) what actually was my "disruptive editing"? Rereading this ANI tread I only read personal impressions, not a factual trespassing. OP Dingley really wrote "I'm sick of this sort of attitude from them." — how could I argue with this? (mind us, this was in their OP ANI complaint) Actually, as I wrote already then, the OP (accusor) failed WP:BRD themselves. So what exactly was my bad behaviour? (Ofcourse, "You were blocked before so you deserve a block" is not sound). As the threads shows, *I* (DePiep) was the one who followed WP:BRD. So please clarify you "disruptive editing" conclusion. -DePiep (talk) 21:41, 25 May 2019 (UTC)[reply]

I am on holiday at the moment and not spending much time on Wikipedia. If you still want me to answer any questions, I should be available sometime next week — Martin (MSGJ · talk) 13:57, 30 May 2019 (UTC)[reply]

Is it possible to override the phase field automatically inserted from {{Infobox element/symbol-to-phase}} in the superheavy element infoboxes? Currently for example {{Infobox oganesson}} reads "unknown phase (predicted)" under "Phase at STP", which is rather odd: it should really read "solid (predicted)", but only for the infobox (so periodic tables should still give it the unknown phase colour). Double sharp (talk) 03:14, 29 June 2019 (UTC)[reply]

 Done: infobox reads {{Infobox element/symbol-to-phase}} by default, and |phase=any text overwrites this value. |phase comment= nicely can have (predicted) and a reference. This overwriting currently happens only in infobox Fr(!) and Z=100 - 118 (Fm-Og); I did not change these infoboxes. Z>=119: phase not shown at the moment. -DePiep (talk) 10:21, 29 June 2019 (UTC)[reply]

Thank you! As for Fr (and At, really): I am a bit sceptical of those figures and will look around for where they come from, since macroscopic samples of these elements have not been made. Probably they will become "unknown phase" when I find out. ^_^ Double sharp (talk) 10:33, 29 June 2019 (UTC)[reply]

OK. You may want to edit (update) {{Infobox element/symbol-to-phase}} for francium. -DePiep (talk) 10:40, 29 June 2019 (UTC)[reply]

DePiep, I thought you had agreed to stop altering the capitalization of "middle ages" back in January, but you seem to have continued doing so, and continued mislabeling it as a "typo" (and labeling your revert as a "minor" edit) in March. Given how you behaved in the January discussion (going out of your way to take offence when I complimented you, and then twice posting "It's resolved -- let's stop talking about it") before going back and doing the same thing two months later with an almost identical edit summary, this seems somewhat tendentious: I would encourage you not to do so again. Hijiri 88 (聖やや) 15:15, 18 July 2019 (UTC)[reply]