Toggling optionsEdit

Right, so here we go.

First of all: I just ask this as a sort of proof-of-concept. No guarantees that it will actually be deployed in articlespace, to make it clear upfront. And I have no intention to argue for it now when Scerri's article in Chemistry International telling us about what the project has come up with is still being written and yet to be published. It is just that I thought it was an interesting idea when SMcCandlish proposed it, and that I can definitely see situations in which I think it would be appropriate. ^_^

Now that that's clear: the idea would generally be to have some sort of thing you could click to flip the PT (or really any template) between various forms. Could be used for Sc-Y-La / Sc-Y-Lu; could also be used for something like He-Be vs He-Ne within the specific context of block (periodic table) for example; could even be for something like showing or hiding the extension or flipping between category sets. I can see a lot of possibilities for it beyond just the group 3 and category things, which is why I think developing it might be a good idea anyway. But you're under no obligation to really do it; I was just curious if it could be done. ^_^ Double sharp (talk) 21:18, 24 November 2020 (UTC)[]

An addendum summarizing my original yakking: It would be a lot of Lua work, and we'd also need to establish what the default output should be (for people running without JavaScript). And "default" might be universal or something set on a per-category/field basis, or whatever; depends on the consensus discussion outcome[s].  — SMcCandlish ¢ 😼  21:29, 24 November 2020 (UTC)[]
I understand. In my testpage I have two technical options. Third one is todo: that would be "zoom" (so not exactly fits here, but a major need for the PT: show overview PT <-> cell details. Example: see US election broadcasts at CNN or NYT: USA map w/colored states, and opening popup with State detailed numbers).
c:Category:Animated GIF files can handle table images, pics &tc, and with various precision (fluid/flickering alternations). No pause option AFAIK. Jscript required?
The map options map zooming (Paris example) are hardcoded in Lua for maps (globe coord calculations!). PT would be easier / hardcoded. Could be cluncky?
Meanwhile, the actual flipping content trbd. -DePiep (talk) 21:52, 24 November 2020 (UTC)[]

Drug links templateEdit

Hi there, just a gentle nudge to ask if there's any chance you'll still have time to work up Template:Drug links? A minimal version that looks like the mock at Template_talk:Drug_links#Mock_drug_links_bar and requires users to manually feed the template links (i.e. {{Medical resources}} but for drug links) would be a great minimum functional solution. If you (or anyone else) ever has time to revisit pulling that data from Wikidata, even better. Thanks a million and I hope you're staying well! Ajpolino (talk) 20:52, 20 May 2021 (UTC)[]

Very inviting (happy face), sure, but cannot promis these days. (sad face) -DePiep (talk) 21:38, 20 May 2021 (UTC)[]
Completely understood. Well if you don't get to it in the next few weeks, I'll take a crack at it. If I set anything on fire, I'll find a noticeboard to go crying to. I hope you're well, and that you're a good kind of busy. Cheers. Ajpolino (talk) 14:42, 21 May 2021 (UTC)[]

Articles with a Chembox not in certain WikiProjectsEdit

Hi, about 5 years ago you did something clever which generated a list of pages containing chemboxes which weren't assigned to WP:Chem. Wikipedia:Chemical_infobox/Articles_with_a_Chembox_not_in_certain_WikiProjects. I was wondering if you would be kind enough to refresh that list? It's a good way of finding 'orphan' articles. --Project Osprey (talk) 09:30, 12 August 2021 (UTC)[]

I will do so. It is a manual process, I remember. Probably some time next week.
Do you want {{Drugbox}} processed too?
-DePiep (talk) 10:57, 12 August 2021 (UTC)[]
I suppose I should be thorough and do both - providing it's not too much trouble for you? Thank you. --Project Osprey (talk) 11:45, 12 August 2021 (UTC)[]
User:Project Osprey: So I check whether all {{Chembox}} articles have one or more of these WikiProjects on their talkpage:
Question: I could leave out ELEMENTS articles, and treat {{Infobox element}} equal to {{Chembox}}, so that all 120 element articles are listed to have CHEM/CHEMS Project. And other ELEMENTS articles are not checked at all.
Question: About {{Infobox drug}}: do I check these against the same WikiProjects? Maybe some bio-pharma drugs (eg vaccines if I am right) are listed too.
-DePiep (talk) 07:41, 14 August 2021 (UTC)[]
I think it's safe to leave out Elements entirely, they're very important, so I'm sure they've already been checked. WP:POLYMER is dead, so ignore them too, any chembox articles they have now need links to WP:Chem. Don't worry about Infobox drug, I'm going to go through the list manually: small molecules we should share with the bio-pharma people but antibodies etc are all for them (we have a claim to man-made stuff produces by chemical means, but 'biologics' etc are outside our area) --Project Osprey (talk) 09:15, 14 August 2021 (UTC)[]
Will do so. Chembox and Drugbox treated alike. (& we can refine afterwards if results are impractical). -DePiep (talk) 09:17, 14 August 2021 (UTC)[]
Thanks you. I probably wont be able to do much editing until until next week, so don't rush. --Project Osprey (talk) 10:29, 14 August 2021 (UTC)[]
  • Oops, Project Osprey, did I promise & forget this ...? Will rescedule it in my agenda (I do like the task, it just needs quiet time to do it). So sorry I let this down. All the best, -DePiep (talk) 18:37, 23 September 2021 (UTC)[]
By a strange quirk of circumstance, I was without the internet for 3 weeks just after I asked. So I wouldn't have been able to do anything anyway. --Project Osprey (talk) 19:20, 23 September 2021 (UTC)[]

Off to a wrong startEdit

As you have probably seen or are about to see shortly, I provided an answer to your request. You will probably not like my response, and as you've probably figured (or are about to figure), I did not like the way you put your request. Still, it's in no one's interest if this disagreement between us spirals into anything else---most certainly, not in mine, not in other editors', and, presumably, not yours---so we better talk this through.

At least, that's what I would normally say. With you in particular, however, I don't believe this will help. Having known you for many years now (you've probably figured it out, but in case you haven't, I used to edit as User:R8R; I'm not really sure if the word "start" in the title is really fitting, but it's going to stay), I have made quite a number of attempts to understand you think and what kind of responses I would get, as well as how to get to you at times. For some reason, that did not work. Maybe you were not responsive, maybe my attempts were misguided; one way or another, it doesn't matter in the end. That fact at hand is that we can't get along for some reasons, and we surely have different estimates of why that is.

I really don't want to have a conflict with you every time I show up. It does genuinely appear to me that you were either asking to change a discussion in a, frankly, rude manner that was absolutely not justified given the context (you were not a part of this discussion), or straight looking for a conflict (and I wasn't even expecting to encounter you to begin with). I don't know which one it is, and it could even be neither; this doesn't matter, either. All I want is to find a way to not have an argument with you, regardless of whose fault that might be. I don't understand how we could come to that in a discussion, however, as I gave it a good thought over and over in the past. With this in mind, I'm asking you for one, and one thing only:

Please leave me alone.

Please do leave me alone, for good. Don't comment on my words. Don't ask me anything. Don't discuss my edits. Don't challenge me or my edits (unless you can specifically point out how I'm violating a policy or a guideline). Don't make suggestions to me. Don't undo my edits. Don't do anything that requires any interaction between us. Evidently, we are not good at that. We tried it; it didn't work.

What's in it for you?

First of all, I would never ask of you anything I wouldn't be ready to provide to you myself. You can stay assured that I'd gladly do all of those things I just mentioned to you, no matter what you do. Second, and perhaps even more important, I'm absolutely sure that other WP:ELEM members would be glad to learn we found a way to put aside our differences, even if it means we wouldn't create something productive together. Here I am, offering you a way out of the conflict, and here they are, seeing this message, likely having encountered it in their watchlist. I suspect it will score you some points with them if you can agree to something they'd approve of. Besides, I can only hope that you'd also gladly take a chance to avoid any future conflict with me in the most productive manner available, right?

In case you're thinking that me editing one article meaning you shouldn't edit it is a restriction that nobody can force onto you, I assure you I can't and wouldn't even try to force this onto you; think of it as more of a gentlemen's agreement or something along these lines, and it obviously can only work if you agree to it.

I really do think that this is the best way to proceed from here. No more disagreements, no more conflicts, no more misunderstandings... no more anything. (And the alternative is to let the nonmetal PR disagreement spiral out into yet another conflict, and risk that over, and over, and over again.)

Please don't think you need to answer immediately; if anything, I'd like it very much if you thought it over for a few days and then given me an answer.-- (talk) 23:24, 28 August 2021 (UTC)[]

I am glad to know that you've heeded to my request to not answer immediately. I know you have read it (your edit history shows you were pretty active in the last week, and there is no doubt in my mind that you read messages on your talk page), and you still were not quick to respond. Thank you very much, I appreciate it (I really do).
At this point, you've surely had the time to think my message through. I'm sure you have an opinion regarding what I wrote, and I hope you wouldn't choose to specifically hide it from me. I might be sporadically back if you accept my request, and I will not be otherwise. Given the weight you have in this, I'm curious to hear what you think. Will you and accept my request and do the one thing I'm asking of you?-- (talk) 12:16, 5 September 2021 (UTC)[]
First of all, I don't need your "advice" to wait answering. Could very well be I advise myself. Also, 'please' stop interpreting my behaviour and prescribing my interests. "you will ...", "you've probably figured it out", "In case you're thinking": stop it. Speak for yourself. -DePiep (talk) 19:07, 5 September 2021 (UTC)[]
Please give me an answer. Yes or no.-- (talk) 19:31, 5 September 2021 (UTC)[]
I did not see a question. Could you strike out the non-question in your text, as already noted? -DePiep (talk) 19:37, 5 September 2021 (UTC)[]
I did not ask a question, I made a request. Therefore, I can't strike out the non-question, and I'll repeat the main idea instead.
I asked you to stay away from interacting with me because our interactions tend to spiral into conflicts. I promised I'd do the same to you if you agreed to it.-- (talk) 19:46, 5 September 2021 (UTC)[]
And it's up to you to either accept my request or reject it, hence the yes or no part.-- (talk) 19:47, 5 September 2021 (UTC)[]
(ec) I can read and reply if and when I want to, and I will do so. You have no business to come here and start commanding me to answer, especially after loading dozens of personal judgements & inferences about me. I already pointed out that you are not welcome to speak for me in any way, and that after doing so you are not to "request" a response. -DePiep (talk) 19:54, 5 September 2021 (UTC)[]
I am genuinely confused. I really did not come looking for a conflict, but it appears one is underway anyway, which was not my intention.
I can see that you said you'd answer in your last post. Good to know. I'll be waiting.-- (talk) 20:05, 5 September 2021 (UTC)[]

Fifteen days ago you said you would reply to my request. When can I expect a response?-- (talk) 13:52, 20 September 2021 (UTC)[]

Don't know. When I have energy to dive into this. -DePiep (talk) 13:54, 20 September 2021 (UTC)[]
Being asked, out of the blue, to shut up on a general discussion page after posts I do not see any harm in is quite a distance to overcome. -DePiep (talk) 13:57, 20 September 2021 (UTC)[]
You see, if you don't set up a deadline, you can always count on a tomorrow to do it. And on that day, you can say "tomorrow" again, and again, and again, and I'm afraid this gives you a way to not stand up to a commitment you've made. Perhaps that's not your intention, but this could happen, and I really wouldn't want to see this; I'd like you to fulfill your promise.
If you can't answer off the top of your head, that's fine, I'm in no hurry and I can wait a few weeks. Just tell me how many exactly.-- (talk) 14:27, 20 September 2021 (UTC)[]
I wrote: 'I can read and reply if and when I want to, and I will do so.' Meanwhile, I don't think there is an issue since I do not edit That Page nor did I meet your edits elsewhere AFAIK. -DePiep (talk) 15:01, 20 September 2021 (UTC)[]
"I don't know when" is just as promising as "never." I hear you. I will think the promise is effectively taken back, although I'll be glad to see a response if one ever comes up and the promise is fulfilled after all.-- (talk) 15:10, 20 September 2021 (UTC)[]
  • Enough for now. I did not ask for this intervention. Nor are there sound reasons for it. Also, it is out of due proces. Telling is that you cannot invoke any policy or guideline that supports your issue or claim. You ask me something, I am free to answer but not obliged to. Let alone that I must follow your wish. The thing you ask is terribly non-wiki. Just re-read my posts to get clear what I mean tot say. -DePiep (talk) 19:55, 20 September 2021 (UTC)[]

Question re tables and templatesEdit

You are way more familiar than I am with creating templates, and so I ask you this question: When a template is used to generate table rows, what is the best way to generate the table headers?

  1. Include the table headers in the page in which the table itself occurs, the page that transcludes the table-row-generating template
  2. Have the row-generating (sub)template also generate the header, either when called with no parameters or when called with a special "header" parameter
    • Advantage: when adding or removing a column, you only need to edit one template, not two.
    • Disadvantage: The if/then/else logic forces you to use special magic words like {{!}}
  3. Write a special-purpose (sub)template to generate the header
    • Advantage: The header-generating-template can be conditionally transcluded in the row-generating template (and vice versa) providing context when each is edited.
    • Advantage: No magic words are needed
    • Disadvantage: Proliferates yet another template
    • Disadvantage: Not possible to edit table and row simultaneously

Do you see any other pros or cons? Do you know if there is any best practice, either a broad WP-wide best practice or a narrower DP best practice? In {{List of aqueous ions}} we started out with option #1, and yesterday I spent a great deal of time and effort implementing #2. But now I am leaning for #3. But having switched horses once, I reckon it is time to ask for advice. YBG (talk) 23:47, 18 September 2021 (UTC)[]

  • First of all, you have described the options and their +/-s very well. I have not much to add for pros/cons.
I have used all options, depending on end usage and development status.
Option 1 is not advisable for mainspace anyway. In secondary pages, like documentation, talk, support, this may well be done. So: an article preferably has templates-all table. (Isotopes of uranium § List of isotopes is still halfway development ;-) ). That is, a /header template and all /row templates can be in the article all right (but usually I move them into the main template; allows for good v-t-e links & footnotes etc).
In development, I start with a crude header hardcoded (i.e. not subtemplate; probably in the main template Template:TemplateName); columns may be numbered first. Then develop the /row template into a final form; header adjustments just follow. If the row is complicated, a subsubtemplate may be useful: step 1 = calculate values once(!), step 2 = format them. If values from step 1 interact & create a new value add a step between: step 1,5 = calculate (eg, [1]: 1. calculate temperatures then 2. compare, then eh 4. report).
This subtemplating for steps can occur in the /row (call subtemplate ../row/format), or in the data retrieval (/data-list has subtemplate /data-list/format; invisible from the row because handled by the /data-list template itself).
Having /header and /row subtemplates but no main one leaves the main template name empty, which confuses editors & leads to deletion-efforts. E.g., {{Periodic table (alkali metals)}} (bad situation still).
If data is pulled from a list (like your aquaeous ions does), handling <ref>s can give complications in value processing (calculating, formatting). I have used {{Plain text}} and considered using {{KillMarkers}} to handle data, but that is tricky, and could create ghost references. IOW, no good practice found yet. Need for {{Plain text}} indicates that formatting should be separated from the data value, and need for {{KillMarkers}} indicates a separate para |foo_ref= or format-option |format=no-refs/refs-only is useful.
In general, if a datalist is used, best is to design & develop that one first into stable & flexible usage. That is: value options, format options. {{Infobox element/symbol-to-saw}} (standard atomic weight) took some years & many versions to develop (while live), but now serves quite well. Row-writing (pulling s.a.w. data with right value, conditions & formats) now is done nicely by parameter options; no subtemplate-calling needed in a row (mostly).
I rarely use the header-in-the-/row-template option. The enveloping big #if:-split complicates editing, while two-tab-editing is just as easy.
If the header is complicated, start its own subtemplate /header anyway. That is: when header has conditional columns (+/- appear), or data-dependent columns (number of colspan varies). For example {{Isotopes table}} (which is the header only, btw) uses the element symbol for various conditional column headings (eg, element has named isotopes?).
BTW, to allow friendly multi-option-parameter like |format=wl, ucfirst I use
{{#if:{{in string|1=,{{{format|}}},|2=%Wwl%W|nomatch=|plain=false}}| wl-HIT | wl-NOHIT }}
Overall, I come to this conclusion. Best practice, for mainspace:
1. The MainTemplate (1-deep name) should be called from the article. Use parameters for options.
2. A data-list, when used, be developed first. Analysis of data structure(s) is required! Preferably split data from formatting. Consider splitting references from value.
3. Two subtemplates /header and /row are easiest to maintain. Durign development, the /header can be postphoned (header hardcoded in main template).
4. A separate /footnotes or /footer subtemplate can be handy.
5. Non-mainspace some compromises can be acceptable (single all-in, formatted data value; header coded in-situ).
HTH. (I see I have a lot of templates to improve ...) -DePiep (talk) 10:45, 19 September 2021 (UTC)[]
  • A good, recent example is {{List of hieroglyphs}}. Clearly, hieroglyph-expert editors can edit the data easily (recognition of the /row parameters!) while the table is stable in formatting.
Recent {{List of chemical element name etymologies}} works technically well too, but has a complicated data structure to show (inherited ...). -DePiep (talk) 10:59, 19 September 2021 (UTC)[]
  • I see you use construct {{#ifeq:{{{symbol|header}}}|header| .... Personally I would not use parameter |symbol= this way, because it is "corrupting" its meaning. Later on or elsewhere such deviation could cause headaches. And in this case the solutiuon is simple: use like |rowtype=header. -DePiep (talk) 15:08, 19 September 2021 (UTC)[]
Thank you for your comments; I am now convinced to go to option 2, /header. YBG (talk) 01:28, 20 September 2021 (UTC)[]
A good thing you found the conclusions! -DePiep (talk) 11:06, 20 September 2021 (UTC)[]

The Signpost: 26 September 2021Edit

Aqueous ion colorsEdit

Do you have any thoughts on which of these is better:

  1. All four colors from
  2. The middle four from

Also, I'm wondering

  • Is there enough contrast between the light gray for "neither type" and the light blue for xA and the light red for xC?
  • Should the same light gray be used for "neither C nor A" and also for "neither xC nor xA"?

Thanks for your opinion YBG (talk) 00:10, 27 September 2021 (UTC)[]

Q1: difficult question. Sure, if there is text on it (black, or wikilink-blue) the contrastr rules will point to lighter shades. (Next issue might be Color Blindness (CB), which is a more serious check but will be easier with only four (in two pairs :-) ) needed; I can give links (WP:PTG) but checking&choosing in CB is a separate process). Apart from this: I tend to look for lighter colors (pastel), in general. Because they are supporting, and should not be shouting. More and more I think the eye is very well capable to distinguish lighter colors. (for example, the new block-colors in main PT are too strong, could be more pastel for the same effect).
That said, re-viewing the two links, I think the lighter ones do not work out well in the checkered area (left-below of the US demo map).
Q2,3: -DePiep (talk) 16:48, 27 September 2021 (UTC)[]
Q1 & Q2: use the 4 darker colors, make the grey a notch lighter (could be ~white).
Q3: I don't think I would look for that difference. Is is a meaningfulll diff, or just a statistic? -DePiep (talk) 16:51, 27 September 2021 (UTC)[]
Are suggesting that instead of using the four middle (lighter) shades from (#2 above, and what is currently implemented in the template), I should use the four outer (darker) colors? I chose not to use that option because of the preference for lighter shades (as you say), particularly because the Z is written over the top of the darker color box. YBG (talk) 18:01, 27 September 2021 (UTC)[]
PS, I thought that part of the point of using color brewer is that it takes CB issues into consideration. YBG (talk) 18:06, 27 September 2021 (UTC)[]
Yes I thought color brewer (argh, "CB" too...) does colorblindness too.
I swithched to "darker", in the end, because the demo-page at CB has small flakes left-below (US districts?), that are hard to color-tell with the lighter ones. However, since you use text (Z), lighter = better (or even: resuired). So be it. -DePiep (talk) 19:10, 27 September 2021 (UTC)[]
OK, lighter it is. BTW, the map in color brewer is the south east part of the US with counties and states. See file:Map_of_USA_with_county_outlines.png. YBG (talk) 01:17, 28 September 2021 (UTC)[]
I'm sorry I have no time enough to dive deeper into this. That's why my replies are sketchy. Didn't find time to look for other options. -DePiep (talk) 05:01, 28 September 2021 (UTC)[]
No worries. You have been very helpful. YBG (talk) 07:56, 28 September 2021 (UTC)[]

Administrators' newsletter – October 2021Edit

News and updates for administrators from the past month (September 2021).

  Guideline and policy news

  Technical news


  • A motion has standardised the 500/30 (extended confirmed) restrictions placed by the Arbitration Committee. The standardised restriction is now listed in the Arbitration Committee's procedures.
  • Following the closure of the Iranian politics case, standard discretionary sanctions are authorized for all edits about, and all pages related to, post-1978 Iranian politics, broadly construed.
  • The Arbitration Committee encourages uninvolved administrators to use the discretionary sanctions procedure in topic areas where it is authorised to facilitate consensus in RfCs. This includes, but is not limited to, enforcing sectioned comments, word/diff limits and moratoriums on a particular topic from being brought in an RfC for up to a year.


  • Editors have approved expanding the trial of Growth Features from 2% of new accounts to 25%, and the share of newcomers getting mentorship from 2% to 5%. Experienced editors are invited to add themselves to the mentor list.
  • The community consultation phase of the 2021 CheckUser and Oversight appointments process is open for editors to provide comments and ask questions to candidates.

Sent by MediaWiki message delivery (talk) 17:03, 1 October 2021 (UTC)[]

A couple of questionsEdit

  1. Do you prefer the aqueous ion row headers be a single column? If so, you should remove the pipe from the middle of your !vote as it indicates a separate column.
  2. What is an F3 search?

Oh, and if you have an opinion on the OS number format (ie +/-), I'd welcome a !vote. YBG (talk) 01:21, 7 October 2021 (UTC)[]


The template {{Periodic table (lanthanides)}} used in this article appears to assign fixed widths for the columns, giving rise to an ugly splitting of the names of the elements when the table is shown. Petergans (talk) 16:00, 7 October 2021 (UTC)[]

By design. The whole (= the overview) is best shown with regular widths (which could be improved in here btw). Given the information per visual row (15 element names) and readability wrt the fontsize, this is the result. So, smaller font or irregular cell widths are not used.
I note that this issue is inherent to the periodic table: there are say 18 columns to show with each cell having (multiple) information elements to show, including text & numerics. There is no solution that covers both. (It is as in a theater: when you have a view of the stage, you cannot see the hedline in a paper the actor is reading. And vice versa). -DePiep (talk) 16:10, 7 October 2021 (UTC)[]