Template talk:Infobox element/Archive 2

Archive 1

Archive 2

Archive 3

About the group names & numbers

Through {{Infobox_element/group}}, we present the group data (number and possible group name). Re this edit by IP 5.43.78.13. It changes this:

Add input option |group=VB to mean group 5, apparently. However, group 5 has also been named VA (in Europa a.k.a. old IUPAC numbering). So this input option is introducing ambivalence. Also, we do not use or present such old group numbers (and if we do, we'd disambiguate). On top of this, that input would link to Group VB element (redlink).

Line breaking: any name itself now is nowrap (through NBSP). That is slightly better than no linebreak at all, but still a bit awkward (see effect in berillium). I propose to improve: within-names a free space, and do not link the added name. i.e.:

group 2 (alkaline earth metals), period 2

So that would be: revert (undo #1), and improve text formatting per #2. -DePiep (talk) 14:25, 28 June 2017 (UTC)

Old IUPAC is old, deprecated, so CAS has advantage and today can be considered as a primary way of naming groups with Roman numbers.

Currently, using |group=VB and similar input is not present; I added it because it might be useful in future.

Redlinks can become either redirect or disambiguation page.

In berillium linebreak does look so bad, it is grouped; I would remove only first   between 'alkaline' and 'earth' because it is three-part item. --5.43.78.13 (talk) 16:43, 28 June 2017 (UTC)

re 1: We're talking an input system here. If ever the some Roman numbers & A/B system is needed & useful in the future, we'll add it then. Not now. And still: the input is ambivalent. What if you find group number "VB" in a source? Is it VA or VB in this new addition? It is ambivalent from the start. On top of this: it is not needed. If you don't know from the source want exact VA or VB it is, then you cannot input it. Same for the redlinks: only when they are actually needed (examples please), they can be added. (You are actually wrioting that the infobox should link to a disambiguation page. What good would that be?).

Maybe you suggest mentioning those group names in the output, visible in the infobox. (input being a regular number 1–18). Then too, one must specify which A/B set this is in. And this too has not been requested.

To only thing I can think of, if ever one want to add those old name(s) to a group, we could add like: "(former group VA or VB)", of maybe ("formerly group V)".

For all this: no need, use or improvement to add them.

re 2: linebreaks: best is to leave linebreaks to the user's browser, unless there is a reason not to do so. The reasons I have is: a) keep "group" and "number" connected (same for "period"), b) keep opening bracket and so 1st word together to show connection. The others are for the browser to process (that's two+one regular space for the example, not 1+1). -DePiep (talk) 17:21, 28 June 2017 (UTC)

Template can be used to output linked group name also outside of the infobox, as it is shown on the template page itself. It is more important to connect numbers with words, but also two words can be kept together for grouping purposes; in examples with three words, one can be ommited. --5.43.78.13 (talk) 18:10, 28 June 2017 (UTC)

It is a /subtemplate, so outside of {{Infobox element}} nothing is guaranteed. Also, outside usage is even more dangerous.

I truly think you need and expect something else. (like: element = Xx, group = ? ). Must say, I'm projecting this template (Lua module). -DePiep (talk) 20:05, 28 June 2017 (UTC)

It can be easily resolved by adding one sentence in documentation: Template requires CAS and not old IUPAC input. or something like this.

What do you think by saying I truly think you need and expect something else.? As I clarified, I added Roman notation so that it can be used if needed because it was easy to incorporate it and matches template title etc. After all, input can be disambiguated by using CAS-VB and IUPAC-VB in switch but I think this is really not needed because we are talking about old, deprecated IUPAC notation; it was replaced by new one and there was a good reason to change exactly these Roman numerals. --5.43.78.13 (talk) 20:05, 3 July 2017 (UTC)

Clear then. Useless, amboivalent, confusing and redlinking change. Will revert. -DePiep (talk) 21:24, 3 July 2017 (UTC)

No, there is no need for revert. Redlink problem can be easily solved by {{delink}} if needed (or by creating redirect, or by adding option to have unlinked output), and if it is currently unused it does not mean it is useless. Ambivalency and confuse are same argument, and it is invalid because I proposed disambiguation (e.g. CAS-VB and IUPAC-VB) or stating in documentation that contemporary CAS is used or other solution if it actually needed. --5.43.78.13 (talk) 22:26, 3 July 2017 (UTC)

I forgot: there is a parameter |group= that solves disambiguity problem (if user does not want group 5 as output for vb, this parameter must be used in order to have other group or Roman numerals notation output. Btw, if you enter VB as first unnamed parameter and want group 5, redlink problem does not occur. --5.43.78.13 (talk) 23:16, 3 July 2017 (UTC)

As you wrote in the es heree, discussion is in progress. That clearly me4ans that there is no consensus for the change you are pushing. See WP:BRD. PLs take this as a warning. -DePiep (talk) 19:09, 4 July 2017 (UTC)

But discussion must not be purposely procrastinated if you have no arguments and/or don't want to answer some questions related to this. Otherwise we are again in the first – BOLD phase, because we discussed and there were no arguments that prove this improvement is undesirable/bad; I explained that all objection can be easily resolved.

I will wait for some time, other users such as Double sharp, Sandbh or Headbomb might want to join discussion... --5.43.78.13 (talk) 22:46, 4 July 2017 (UTC)

Styles in neighbouring elements

I propose to remove the multiple stacked style settings in neighbours, but it was reversed [1]. However, this ratio (do not add attention by both bolding and by larger font and by larger line-height) was declared "invalid" by IP in their es. This is a mistake (the ratio is valid), because it is a style choice. That is can be done by stacking style settings does not mean it is good to do. This being a wiki, that users are "used to" is not an argument to stop a change/improvement/correction. -DePiep (talk) 22:00, 3 July 2017 (UTC)

These "settings" are not in neighbours but first style is of table and second element with its style property in table cell content (which is very common). Even if it was closed like </span></span> i.e. real nested elements it is not any problem and functions properly.

No, your ratio was "bad to use two style effects together. no need." and I declared this as invalid. That ratio, do not add attention by both bolding and by larger font and by larger line-height, can also be described as invalid because it is not applicable in this case nor points to any MOS guideline (btw, I guess larger line-height is to compensate larger font-size so it does not count as third item but I'm not sure; also, we have both bold and increased font-size in infobox title, let's say, or in headers etc. so this is not true what you say: that it is [always] bad to add attention by multiple emphasizing styles). However, thing is that you were removing already present style (I mean on font-size) without discussion. We need more users than two of us to join discussion in order to get consensus about font-size change.

Font-size can be changed as <strong style="font-size:150%"></strong> and – just to say – there is actually no big difference between span and strong as these are elements (you stack strong to table style, I stack span to table style).

Style choice is different when we are talking about simple alignment (centering or fixing wrapping), but when we are talking about font-size or italics or bold discussion is needed (people, readers, are used to see bigger element name and symbol when navigating PT in IB + it is easier to do this with bigger clickable part). Stacking elements is not bad either, it is done very often and is common in HTML (we stack span into div, big into already nested span etc.).

Decresing font-size might be no improvement/correction because we don't have valid reasons to do that and have valid reasons not to do that (two cited above + it simply looks visually better when middle parts are enlarged a bit + it was there on 110% for many years [since you created it; 11:51, 7 July 2014‎] so rash resetting to 100% is not advisable).

PS You did not explained why you removed linking in all pages; selfref causes problems only on article pages i.e. pages with title equal to element name; I used ifeq to detect if we are on article page in question and if we are – don't use [[ and ]], if we are not use normally [[ and ]]. You wrote that it was incomplete change or something but I don't understand what you meant by this.

PPS I completely disagree with removal of first label and data with element name and symbol because it was useful to have it there simply written next to each other (comma-separated) and easy selectable (because it is unlinked, with normal font-size, not bolded etc.) for possible copy-pasting elsewhere from Wikipedia article. Could you point me to the discussion done before removal of this part? --5.43.78.13 (talk) 22:51, 3 July 2017 (UTC)

• The code had this: <span style="font-size:110%; line-height:110%; font-weight:bold;">{{{name}}}</span>. That is: three css style settings, changing from the environment (style settings). Three. I maintain that it only takes bolding ("strong") because it is the article title (element name = bold). Additional style effects are not helpful, and may be bad for reader's view perception (irregular text).

I removed the wikilink that did link to the self-page (with the effect: bold but not linked). Ratio: the infobox is only used at that element page. Self-linking is useless, and even may create wrong effects. It is enough that the element name is strong (bold). (BTW, I originally added that link to make template maintenance easier for myself... So that on page Template:Infobox hydrogen, I could more easily click to page hydrogen. Such tricks should not end up in mainspace). -DePiep (talk) 17:16, 13 August 2017 (UTC)

Visual issues

Now that oxygen is TFA, some quirks caught the eye:

• With the micro periodic table, element name is excessively styyles (lineheight, bold, font). Just set to bold (strong) is enough. Already explained at talkpage. (Done [2])
• Mobile view: micro periodic table: between groups 1 and 2 extra whitespace visible (to fill the PT width?) (Gone now)
• Mobile view: tables "Vapor pressure" and "Main isotopes" bottom row has incomplete borders (missing or witdth (pixelsize) not bold).
• Mobile view: bottom row (v-t-e links) has uneven vertical whitespace.
• Mobile view: shows empty data row below atomic weight (Solved, had to do with abundances).

-DePiep (talk) 07:20, 5 September 2017 (UTC)

Grammar

This template offers the possibility to include the "most stable isotopes" of an element. I learnt that adjectives in two syllables build their comparatives and superlatives with -er and -est, respectively, when ending in -le, -er, -ow, -y, and -some. So shouldn't it be stablest isotopes? Steinbach (talk) 14:59, 28 October 2015 (UTC)

I see that wiktionary:stable lists both comparative forms. In this native speaker's idiolect, more/most stable sounds OK but stabler/stablest sound really weird. Can't explain why. YBG (talk) 17:05, 28 October 2015 (UTC)

It's probably the old fashioned formalised English this non-native speaker learnt at school... Steinbach (talk) 17:26, 28 October 2015 (UTC)

Could also be a dialect I'm unfamiliar with. Didn't you know that we English-speakers provide a multiplicity of dialects for the sole purpose of causing trouble for you non-native speakers? YBG (talk) 18:28, 28 October 2015 (UTC)

"Stablest" sounds almost as wrong to my ears as "goodest", though I agree it is not wrong technically. "Most stable" doesn't evoke that response, so it looks like as long as both are correct, we aught to retain "most stable" for now. KDS4444 ^(talk) 02:31, 17 October 2017 (UTC)

Respell

I would like to remove the ugly and redundant {{respell}} field from this template. IPA is fine for helping those who are unsure how to pronounce the name of an element. It adds nothing to the informational content, it clutters the infobox, and it is unnecessary for most elements. It looks particularly silly on articles like gold and silver, but it is not an asset anywhere. --John (talk) 16:45, 23 February 2015 (UTC)

Ugly is an opinion. "IPA is fine" is not true generally. If I remember well, its usage is OK (provided next to IPA, not in place of), but maybe there is a guideline or background to not use it? -DePiep (talk) 17:43, 23 February 2015 (UTC)

Is there a guideline or background to use it, should be the question. Is there? --John (talk) 17:46, 23 February 2015 (UTC)

No that not "should be" the question. You simply can asked that yourself instead of imposing it. And no, there is no obligation to use it AFAIK, if that is what you try to ask. -DePiep (talk) 17:55, 23 February 2015 (UTC)

Cool, so you are ok with removing it then? --John (talk) 18:53, 23 February 2015 (UTC)

Fallacies. No removal then. -DePiep (talk) 18:57, 23 February 2015 (UTC)

It's not very clear to me what you are trying to say. I'll give it 24 hours and if there is no convincing rationale to retain this field I will take it down. --John (talk) 19:24, 23 February 2015 (UTC)

In short: what part of "no" do you not understand? And what you do is no base to conclude consensus.

Longer: I've responded three times, and you kept coming back with new sidetracks instead of engaging in the responses I gave. I note that your replies are directive towards me, not open or searching. Neither did you ask or search for clarification. (and strangely: at 18:53 you first conclude, then at 19:24 you say it's not not clear). Your jumps in approach and suggestion of logic do not hold.

On top of this, you impose a requirement that you must be convinced or else ... But the thread so far does not show that you are open for being convinced of anything. Rationales already in there you did not respond to. Also, the "24 hours" can be read like a threat not an invitation, where there is no such a deadline in wikipedia.

All in all you are still invited to build a conversation here. On the other hand, if you enforce your own thoughts as "consensus" you are wrong. The announced edit would be without consensus (and so explicitly is not to be done). You are an experienced editor, so this is not new to you. You could pick up by connecting to my first reply. -DePiep (talk) 09:54, 24 February 2015 (UTC)

What part of "Why?" do you not understand? If you are not able to present a convincing rationale for why this redundancy needs to be maintained by this evening then I will take it down. It's really very simple. --John (talk) 12:40, 24 February 2015 (UTC)

Which 'why?' are you talking about? You did not ask such a thing. Why don't you reread the thread and create a conversation? (warning, John: your statements here do not consitute a consensus or coherent solution, and your repeated announcement to edit one-sidedly may be read as a threat to editwarring). Again, you are invited to make this a conversation. -DePiep (talk) 17:26, 24 February 2015 (UTC)

• I realize this conversation is now stale, but I wanted to weigh in: I have to agree with John here: I see no reason to include the respell information for these elements, and not even a reason to retain the IPA for most of them— the current MOS for adding the IPA template to an article says that this should only be done where the pronunciation is in some kind of doubt, but I don't think that any English speaker needs guidance on how to pronounce "gold", and having it here looks more than a little silly: ev-ree-bod-ee nohz hou tu sey gohld, dohnt dhey? Also, and on another point: it looks to me like DePiep is not a native English speaker ("ratio", etc.), and may want to defer to such speakers when it comes to understanding what is being said and understood on the English Wikipedia. I myself could not tell what DePiep was trying to say at times, and John's confusion looks perfectly justified. Just sayin'. KDS4444 ^(talk) 02:19, 17 October 2017 (UTC)
  • Thanks, KDS4444, for chipping in. My opinions haven't changed in the last two and a half years. Having this (even relatively hidden away in the infobox) is a detriment to our articles. --John (talk) 11:33, 17 October 2017 (UTC)

• John, Then what do we need to do to have it taken out? Will this take a whole RfC? (ugh). If that's what's necessary, I will be willing to submit one. The fact that there has been any resistance at all to the idea makes me suspect that this may be the only way forward on this. KDS4444 ^(talk) 22:46, 22 October 2017 (UTC)

• An RfC seems like the way forward here. --John (talk) 22:48, 22 October 2017 (UTC)

• Okay, man, then here it comes! KDS4444 ^(talk) 22:50, 22 October 2017 (UTC)

• Actually, KDS4444, I red your comment here as an ad hominem, so I didn't feel the need to reply. -DePiep (talk) 23:02, 22 October 2017 (UTC)

Parameter Latin name

The Latin names of the elements have special historical importance as the international interlingual form and thus also as the etymon of the symbol. An improvement to the daughter infoboxes of Infobox element would be if the parameter Latin name was entered. Right now the en.WP articles are inconsistent about including the Latin name or not. For example, it is in the lede of the sodium article but is nowhere in the hydrogen article. Instead it should just be in the infobox of every element article. I plan to implement this. Quercus solaris (talk) 14:15, 28 September 2017 (UTC)

I suggest: phrase in 1st sentence: "(from latin x)" when clarifying name or symbol. Otherwise: not in lede nor infobox. List of elements affected: ... -DePiep (talk) 19:53, 28 September 2017 (UTC)

W for tungsten is not really from Latin (snce native Latin words have no W). The source wolframium you will sometimes see to explain it is really a borrowing from German Wolfram. And I highly doubt some of the more recent namings have anything to do with the Latin names, since they very much postdate Latin's dominance in the sciences. I would say that the Latin or other names are useful only when they explain the symbol, that otherwise is not clear from English (Na, K, Fe, Cu, Ag, Sn, Sb, W, Au, Hg, Pb). Otherwise they are not illuminating anything. Double sharp (talk) 06:32, 31 October 2017 (UTC)

Adding Term symbol as chem element data: implementation

#Above, it is discussed to add Term symbol to Infobox element

Here, about the implementation, especially in other places (for example, the Infobox PT group)

I can add it to the template, when this proposal is supported here. I myself am in doubt: isn't it too much detail for an infobox, better in place in a data page?

So if this proceeds, what would be the label text? "Term symbol"? If I understand correctly, per this section, we can expect same value in each group? Or is that in a [{{Periodic table (left step)}} group? -DePiep (talk) 18:31, 8 November 2017 (UTC)

• Sbharris: Please check and edit {{Infobox element/symbol-to-electron-configuration}}. -DePiep (talk) 23:30, 8 November 2017 (UTC)

Oh, I see them now, and will add more.... No, I can't. Try as I will, I cannot figure out how to edit this page to add missing term symbols.

I have in mind either putting it just after electronic configuration, or under it. Some tables have it right after, as in the example above.

To answer your question, no, it's the same for all elements in a group only in s and p block groups. For d and f block elements (groups 3 to 12, plus lanthanides and actinides), it's the same in the entire group only about half the time (half of the groups). If it was the same all the time, we could save ourselves the bother, and just at it as a column descriptor in some table. As for it being only wikidata class material, I think it's important enough to include, partly because it's hard to find. Probably that's why it's in WebElements-- they couldn't FIND it anywhere else. SBHarris 00:42, 9 November 2017 (UTC)

... development talk ...

Good you tried! I did not want to patronise beforehand... It will be OK. -DePiep (talk) 01:38, 9 November 2017 (UTC) The page you can edit is: Template:Infobox element/symbol-to-electron-configuration/term-symbol‎. The good news: this input-once will be used all-over in infoboxes (no need to repeat input then). It has the {{#switch:{{{1|}}}| ... = ...}} pattern. |1= is the element symbol (like C, Si). In the rows, you see elements symbols listed, for example: The carbon group (14): | C | Si | Ge | Sn | Pb | Fl = <sup>3</sup>P<sub>0</sub> The zinc group (12): | Zn | Cd | Hg | Cn = 12 The #switch trick is, that all input symbols (elements) before an =-sign get the after = sign value. If you want to give say Hg a different return value, make it look like this: | Zn | Cd | Cn = 12 | Hg = XYZ After every edit, you can check page Template:Infobox element/symbol-to-electron-configuration/term-symbol‎, but do click the "purge" button to refresh (update the page). Does this help? -DePiep (talk) 01:38, 9 November 2017 (UTC) Let me quote what you wrote on my talkpage: "I presume you got them from the little discussion in the term symbol article. However, that's as far as we can go. Groups 3, 4, 9, 11, 12 plus 9/14 lanthanide/actinide 2-columns, have the same term symbol. But in the other columns/groups, it varies and will need addition by hand. [...] The ones you have must be transcluded from yet someplace ELSE. And we're reaching the limit of how far we can push that." I don't understand all of this. The point is: in page Template:Infobox element/symbol-to-electron-configuration‎, you can enter the return values per element: | H = blabla for H | He = this for He | ... The grouping I thought was conveniant (easy). You prefer list it per element? I can adjust. -DePiep (talk) 01:52, 9 November 2017 (UTC) Prime issue: we can add per element and, when preferred & easy, group them: | H = blabla for H | He = this for He | C | Si | Ge | Sn | Pb | Fl = <sup>3</sup>P<sub>0</sub> Would yo like a full individual element list to start with? (like this)? We can do that. It's just, you will have to enter those actual correct values for 118 elements ;-). Only once. -DePiep (talk) 02:08, 9 November 2017 (UTC) Okay, thanks. Here they are. Ready for transclusion, I think. I would have figured it out, but the correct edit tab was not the main page one, but the one NEXT. But not any of the ones after THAT. I missed it. Anyway, thanks for the format so I could enter blocks of elements (even two) with the same term symbol. That made it as painless as possible. I've stopped at element 107 (Bh), as everything after that has much more questionable electron configuration. Now, if we could get a periodic table which had nothing but element symbols, electron config, and term symbols, we could use it to illustrate both the electron configuration article and the term symbol article. It's interesting to see this all in one place. Example: look at the spin of 4 for Gd (9-let). No wonder it's such a good MRI magnetic contrast material. Thanks again. SBHarris 03:50, 9 November 2017 (UTC) Good. I learned that it is not that much a group thing. BTW, when sorting, shouldn't that be by the letter first? (Can be added). I think that PT you have in mind may come, but wrt me it might take some time. -DePiep (talk) 11:18, 9 November 2017 (UTC) Can you repeat your first question? I don't understand it. When sorting what? Term symbols sort like electronic structures, since the structure outside the inert gas config is all that contributes. That goes mostly by column, but as you see, not entirely. SBHarris 03:29, 11 November 2017 (UTC) Sbharris let me rephrase: I see that the groups do not form a pattern in general (only a few froups do). OK then. About sorting: see Template:Infobox element/symbol-to-electron-configuration. If you sort the table by Term, it sorts all 1 values first, then the 2 values etc. But. Maybe it is better to sort per letter first, then (seconday sort) by superscript number. So it would look like: 1S0 | 2S 1⁄2 | 4S 3⁄2 | 2P 1⁄2 | 3P0 | (that is: all S's first, then all P's. Within a letter 'S', sort by superscript number) etc. or if there is an energy value for each, sort by that value? -DePiep (talk) 14:01, 14 November 2017 (UTC) Next step: should we improve the table, so it can be into article Term symbol? I guess we'd have to add the electron configuration for each element. -DePiep (talk) 14:03, 14 November 2017 (UTC)

Yes, they aren't really energies, so there's no useful way to sort them really except in the way you'd "sort" electronic configurations. Since they correspond to electronic configuration outside the inert gas shell, the biggest regularity in term symbols is seen when they are put into a periodic table, which I highly recommend as an illustration for the term symbol article. You can see there are only a dozen cases of elements that don't go with the rest of their "column" in the table (even if you count the "two-column" lanthanides and actinides). The single-column table is okay for looking up a particular element, but it's not much better for that than a periodic table, and the "periodicity" of the term symbol changes is hardly appreciated on a single-column table. It's exactly the problem of Mendeleev-- how to illustrate this best? Meanwhile, yes, I'd like to see "atomic term symbol" or simply "term symbol" added after electronic configuration, for each element, in the infoboxes. SBHarris 23:41, 14 November 2017 (UTC)

OK, in a periodic table. -DePiep (talk) 07:20, 15 November 2017 (UTC)

A place for ground state term symbol after electronic configuration

For adding this to {{Infobox element}}, please continue discussion here.

For adding this to other places wrt chemical elements and templates, please see #below. -DePiep (talk) 23:19, 8 November 2017 (UTC)

If you look at the article on Russell-Saunders spectroscopic term symbols, you will see that they are not easy to calculate for atoms in many cases, and are somewhat hard to find for the ground states of the various chemical elements. So they are a good thing to have tabulated somewhere. However, when they can be found (use Google) you will see that they are in rare other databases for the chemical elements, the most widely available being WebElements, and there's nothing formal in Wikipedia. We can't have that!

I added a little paragraph to the term symbol article noting the columns in the periodic table that all have the same term symbols (all the stable S and P block elements), but about half of the D-block and F-block columns don't have the same term symbols for all their elements, owing to nonuniformities in electron configurations.

I will work on this a bit more in the term symbol article, but I propose that we do what WebElements has done, and put the ground state term symbol in the infobox, after the electron configuration. Thus, carbon would be electron configuration [He] 2s2 2p2 term symbol ³P₀. (And those who notice that carbon is thus C 3P0, it's really C3Pzero, and I don't think has anything to do with Star Wars. But who knows?).

Anyway, I need somebody who knows this template to add a term symbol row after electronic configuration, and have it be something that shows up as "term symbol" (ground state) in Wikidata, so we (or I) can put in all these. Does anybody disagree? Would anybody like to help?

In a related issue, I have not found any periodic table on WP which has only element names and electronic configurations. It would be nice to make one, or if it already exists, to add the term symbols to it, since they follow the electronic configuration in the expected way, so you can see patterns and the lack of them. Such a table would be a nice addition to the Periodic table article, and of course the term symbol article also.

SBHarris 03:45, 1 November 2017 (UTC)

• It looks like this is too subtle a detail to be displayed in the infobox. That is not to say we can't include this in Wikipedia somewhere, say, in Term symbols of the elements (data page); but frankly, the infobox is already overloaded and this doesn't appear to be essential information for an element, which should be the prerequisite for inclusion in an WP:INFOBOX. If this is not included anywhere, it rather shows we don't need this in the infobox if anything. Again, I want to make it clear that I am opposing only inclusion in the infobox, not Wikipedia in general.--R8R (talk) 08:28, 9 November 2017 (UTC)
• Conclusion. By now, the values are entered by initiator Sbharris, available by centralised template. See the overview table here. In this talk, and in the technical discussion #below, SBHarris has made clear that best is to add this data in a dedicated periodic table (that is, a PT with elconfig and Term value per element). That PT should go into Term symbol.

About adding to {{Infobox element}}: I conclude that is not supported here. -DePiep (talk) 09:26, 15 November 2017 (UTC)

Substantial change proposed

A substantial change to this template has been proposed at WT:ELEM. Please feel free to take part in the discussion.--R8R (talk) 10:11, 23 November 2017 (UTC)

Pronunciation data: redesigned handling and formatting

Note: this is about a change in handling and presenting pronunciation. It is not implementing or enforcing any (future) outcome of the RfC on Respell above (2017-10-27).

I have redesigned the handling and presentation of the pronunciation (pron for short) parameters in {{Infobox element}}.

Design goals

• Centralise data (IPA and respell pronuciations). This allows overview, checking, and possible reuse elsewhere.

Data: {{Infobox element/symbol-to-pronunciation}} (has full data list)

Data was read from the infoboxes as of 2017-11-28.

• Standardise presentation (formatting) in {{Infobox element}}.

Use subtemplate: {{Infobox element/pronunciation}} (tests)

{{Infobox element/pronunciation/demo|symbol=H |show ref=no}}
{{Infobox element/pronunciation/demo|symbol=Al|show ref=no}}

Setup

• Internally, elements are identified by their symbol.
• Each element can have a pair for one pronunciation: IPA1, respell1 (=pair1). Some elements have two (or three) pron variants, making pair2 (and pair3).
• In the infobox, presentation is in this order and form:

• IPA1 (respell1), or
• IPA2 (respell2), or
• IPA3 (respell3)

So each pair starts at a new line (in an {{unbulleted list}}).

Note that this eliminates the order IPA1, IPA2; respell1, respell2 that some infoboxes had.

• The list is wider than a regular infobox column (left margin is smaller) to allow longer data rows nicely.

Update: text now fits in regular data-space (right column).

• The view should be OK in mobile view too. Check done. One minor issue: while the {{respell}} uses {{nowrap}}, mobile screens do break a respell at a hyphen. Update: while it now fits in regular data column, mobile shows an indent that misaligns of the lefthand of the data. (minor wrt the overall improvement). (Solved, with me -DePiep (talk) 11:27, 29 November 2017 (UTC)) (Almost. Mobile view has (invisible) bullets in {{ubl}}? -DePiep (talk) 11:45, 29 November 2017 (UTC))

Further development

• From now on, live data is in the central data pages (not in individual infoboxes).
• The data overview is an invitation too take a good look and check all values.
• It shows that some 15 respell-values are missing. Also textual additions may be up for rethinking.
• Both data list (overview of all IPA and respell values) and the formatter (as showing) may be up for improvements. Still, I guess this first version already is an improvement and so is a base to be improved upon (IOW, I see no reason to wait for perfection).
• Note. As said, this is not the place to discuss/enforce any (mass) RfC results.
• Announce individual changes as you would do before (article talkpage?). Formatting issues are welcome here.

-DePiep (talk) 20:10, 28 November 2017 (UTC)

• Update: improved presentation: pron data now fits within data space (no widened lines needed). -DePiep (talk) 10:54, 29 November 2017 (UTC)

References

Comments

I'm afraid I have to say this isn't really well put together. I think all notations should be concentrated in one page (or just leave it to each element's page as it's been).

• A respelling must always correspond to its preceding IPA notation. Having separate pages makes it a hassle to make sure they agree with each other.
• An element might require three or more notations.
• As we discussed above, if we were to stick to WP:PRON, not all elements would need a respelling.
• As we discussed above, if we were to stick to WP:PRON, not all elements would need a notation. We could make it possible to toggle the visibility of the pronunciation at each infobox, but at that point we might as well leave the whole pronunciation to each infobox like it's been.
• A respelling is usually not enclosed in parentheses but put right after the IPA with no punctuation but a space.

Overall, this strikes me as an overly complex solution to a much simpler problem with little regard to making it easy for everyone to maintain. I appreciate your effort, but that's my two cents. (cc: Mr KEBAB) Nardog (talk) 13:53, 8 December 2017 (UTC)

• Replies.

1. I agree, it is more complicated having the input over a set of pages (under {{Infobox element/symbol-to-pronunciation}}, with overview). Main advantages are that it is systematical, it allows the overview, and these pronunciations can be reused in other pages (as is done with atomic weight and top image). If the general opinion is with you, I best change it into |ipa1= (6x) parameters in the infoboxes. Would loose the overview, and the reuse option.
2. Yes the pron pairs must agree. One of my goals was to make that check easier, by having them in one overview. I could put a little bet on it that you, pronunciation-interested, actually did make such a check now ;-) ?
3. This is a technical change, no claim wrt WP:PRON is made. IOW, if a pron should be changed or deleted, that can be done and is not prejudiced (hindered/promoted) in any way.
4. I added the parenthesis to support the visual distinction between those two forms. For me (a layman in pron), I am happy to see that distinction especially and nicely since IPA has /.../. And please note how this works out in the more complicated situations with 2 or 3 variants. Those need visual support even more. In an infobox (not in an opening sentence), the situation "right after" is different (expect soft new line more often).

Thanks for your input. -DePiep (talk) 22:09, 9 December 2017 (UTC)

If leaving it all to each infobox is inconvenient for you, what if we made Template:Infobox element/symbol-to-pronunciation something like this?

{{#switch:{{{1}}}
|H={{IPAc-en|ˈ|h|aɪ|d|r|ə|dʒ|ən}} {{respell|HY|drə|jən}}
|He={{IPAc-en|ˈ|h|iː|l|i|ə|m}} {{respell|HEE|lee|əm}}
|Li={{IPAc-en|ˈ|l|ɪ|θ|i|ə|m}} {{respell|LITH|ee|əm}}
...

This would allow for an overview without having too many pages to watch and maintain. Nardog (talk) 23:25, 14 December 2017 (UTC)

If this centralised data is not desired, the infobox would get six parameters (eg in infobox H: |ipa1={{IPAc-en|ˈ|h|aɪ|d|r|ə|dʒ|ən}}, |respell1={{respell|HY|drə|jən}}); formatter works in the background and stays unchanged). Point is to split data and formatting.

Note that we'd lose the reusability (something that, for example, similar standard atomic weight setup already uses). Also, I like to hear what exactly is the problem with today's setup. IMO the overview + links is OK. Per-infobox data would loose the overview option btw. -DePiep (talk) 00:06, 15 December 2017 (UTC)

Point is to split data and formatting. And why would we want to do that? Specifically, the number of pronunciation variants for a given element is not predictable. So splitting them would most likely result in invoking empty strings―unless one wants to show only the first variant(s), but in what circumstances? We have multiple variants exactly because an element is pronounced in multiple ways and we want to show them, and to hide some of them would be WP:UNDUE.

Also, I thought we agreed that not all elements need an IPA (like gold) and not all IPAs need a respelling (like cobalt). So some elements will have no pronunciation and some IPAs will have no corresponding respelling. Thus, again, we would be invoking empty strings if we split them.

we'd lose the reusability Not sure if I follow. In my proposal reusability could be achieved by e.g. {{Infobox element/symbol-to-pronunciation|H}}, which would yield {{IPAc-en|ˈ|h|aɪ|d|r|ə|dʒ|ən}} {{respell|HY|drə|jən}}.

what exactly is the problem with today's setup I named them above in bullets. But the biggest is the first one, i.e. that variants for each element (ipa1, respell1, ipa2, respell2...) are split on several pages. To me it is unacceptable all pronunciation notations for one given element, which of course would end up in the same article, are not aggregated on the same page. I don't care an overview is provided. What is important is that all notations for the same element should be seen within the same page when editing. So I would rather a structure like /H, /He, /Li... under Template:Infobox element/symbol-to-pronunciation than the current setup, if not my proposal above. Nardog (talk) 13:00, 19 December 2017 (UTC)

RfC regarding use of Respell key for the names of elements

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Should the Infobox element template retain the {{respell}} tag/ parameter? KDS4444 ^(talk) 22:56, 22 October 2017 (UTC)

Background

As can be seen from higher up on this page, there has been some disagreement regarding the utility of having all elements have a respelling key for their pronunciation, especially for elements like copper, gold, silver, etc. whose pronunciation is already obvious to English speakers. Such keys may be useful for elements with uncertain pronunciation (Yttrium, etc.) but having such a key for most other elements is redundant (oxygen, lithium, silicon, and most others). The MOS regarding the use of IPA and respelling keys says that they should only be included where the pronunciation of a given word is in doubt. That is seldom the case with the elements. A respelling key can always be included for those elements with uncertain pronunciations, but right now it is a standard parameter for the template and means gohld is now added to the article on gold. Please leave your thoughts below. Thanks! KDS4444 ^(talk) 23:03, 22 October 2017 (UTC)

In the "above" discussion, titled #Respell for a reason, the question is to remove any {{Respell}} at all from pron in the infobox. However, now this RfC question is about removing all pronunciation (including IPA) e.g, for "gold". Confusing. -DePiep (talk) 23:15, 22 October 2017 (UTC)

• MOS: WP:MOSIPA or Wikipedia:Manual of Style/Pronunciation
• I note that the requesting editor has been indef banned [3]. (Does this imply their comments (below) should be struck/removed/nullified?) -DePiep (talk) 16:22, 28 November 2017 (UTC)

Survey

• Oppose 1 rm pron all: IPA pronunciation is there for a reason Withdrawn, is not in the RfC question. -DePiep (talk) 11:32, 23 October 2017 (UTC)

Oppose 2: When IPA pronunciation is present, {{Respell}} should be too.

Note: not in this RfC, but when 'gold' doesn't need pron, OK with me. (That's: no IPA, no Respell then). However, this is not proposed. -DePiep (talk) 23:28, 22 October 2017 (UTC)

See my comment below (I support later !votes that say "keep the pair, but only when pronunciation is not simple"). -DePiep (talk) 18:47, 28 November 2017 (UTC)

Support removing respell, oppose removing all guides from common elements. I mostly agree with this idea: I think the respell key is redundant (and at worst is misleading, like in cobalt), and would be happy to leave only the IPA. I also agree that the most common elements do not need IPA because their names are part of everyday speech: it is doubtful if someone who does not know how to say "iron", "copper", "gold", "tin", or "silver" can be said to speak English competently. But there is something to be said for consistency, especially when the line between what needs pronunciation is in doubt and what isn't is blurry. I think we can all agree that "technetium" and "lutetium" need a pronunciation key (since it is not obvious from the spelling), whereas "iron" and "gold" do not. But what about the ones in the middle? "Samarium" is not a common English word, but the spelling leaves nothing in doubt: it can't really be anything else. Does that justify a pronunciation key, just because the word is not common? And then you have "iodine", which has two common pronunciations, even though the word is common because iodine solutions are a common disinfectant. And is it obvious in the noble-gas names "argon, krypton, xenon, radon" that the vowel in the second unstressed syllable is not reduced to schwa? I think I would prefer to stomach IPA for gold and silver than get caught up in ultimately pointless side arguments on what is and what isn't obvious. In any case, the respelling is redundant (especially with the mouseovers and links for the IPA) and can safely be jettisoned. Double sharp (talk) 06:26, 31 October 2017 (UTC)

The question is not been made to remove both pronunciation keys (not in gold, nor elsewhere on whatever grounds). The question is to solely remove {{Respell}} from all these infoboxes. Also, the 'redundant' claim is not correct. These two reasonings have lead Double sharp into the wrong (b/c misguided) conclusion. -DePiep (talk) 09:19, 31 October 2017 (UTC)

I assure you that I understand very well what he meant and what I meant. And yes, assuredly the respelling is redundant, because it corresponds in a strict bijective mapping to the IPA as seen at Help:Pronunciation respelling key. Double sharp (talk) 10:28, 31 October 2017 (UTC)

"What he meant", is that different from what he wrote? How can we know? Already before, I asked for clarification. -DePiep (talk) 10:36, 31 October 2017 (UTC)

It is the same. Since he has asked two questions – one about respelling, and one about both IPA and respelling – it seems clear that we should answer both of them. Double sharp (talk) 12:04, 31 October 2017 (UTC)

Double sharp: this RfC asks: "remove all Respell", and does not ask anything else. Please keep answering that question. (My answer is: no, don't.) -DePiep (talk) 22:24, 7 November 2017 (UTC)

I have already answered that question, supporting the removal. Double sharp (talk) 06:36, 8 November 2017 (UTC)

• Leave both parameters but have both be optional. As a native English speaker I find respell much easier to read than IPA, so I appreciate its presence on elements that are hard to know how to pronounce. It is true that for some elements that are common words the parameter is unnecessary. CapitalSasha ~ talk 05:30, 1 November 2017 (UTC)
• Leave the features alone (for both pronunciation keys), but remove from articles where not helpful, the standard approach to dealing with non-useful information in infoboxes of any kind in any article category. This is "blaming the tool for poor workmanship".  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  13:28, 8 November 2017 (UTC)
• Remove the notations for common words, don't remove the respellings but don't make them mandatory either – which is what Wikipedia:Manual of Style/Pronunciation already prescribes. I don't see anything that should be added as an instruction (cf. WP:CREEP). Nardog (talk) 13:42, 8 November 2017 (UTC)
  • Seconded. Let's not create instructions for creating instructions' sake. MoS already covers that. Mr KEBAB (talk) 21:32, 14 November 2017 (UTC)
• Leave both parameters Personally, I have always found respells easier to use. In addition to that, I completely agree to the idea that we should not create special rules when a general one applies well. I could suggest make the parameters optional to account for common names but they already are.--R8R (talk) 06:53, 9 November 2017 (UTC)
• Comment: Above, I opposed removing just the Respell. Now that multiple people have strongly clarified that Respell should stay to make a pair, but that not every element need an IPA/respell pronunciation, I fully support that result, as it is most obvious & per our guidelines. -DePiep (talk) 18:47, 28 November 2017 (UTC)

Discussion

• Unclear RfC question: to remove "Respell" or to remove all pronunciation? -DePiep (talk) 23:10, 22 October 2017 (UTC)

It's worse. here KDS4444 engages in personal attacks and degenerations. Also, KDS4444 does not seem to understand the difference between adding pronunciation by IPA and by Respell. (Which, of course, caused this RfC to be uselessly indifferent). -DePiep (talk) 23:39, 22 October 2017 (UTC)

Non-argumental side issue involving a now-banned user

Dude... I sorry if I offended you, but I had difficult understanding some of the text you had written and wanted to point out how understandable such confusion might be and why. I am also not sure I understand the meaning behind "uselessly indifferent"— people can be indifferent, but not topics. Maybe you meant something like "directionless" or "inept". I understand the difference between respell and IPA at least as well as you do, and I do not think the respell is helping these articles. The MOS says that IPA is just fine without respells— nowhere does it say both must be used or neither. We can retain one and not the other, and we can retain both for unusual elements and include neither for mundane ones. Keeping both for all elements and insisting that this be done because you believe the RfC was malformed despite agreeing that the idea might be valid seems like the opposite of WP:IAR: it is insisting on the adherence to a rule despite it being obvious that doing so does not improve the project (?). KDS4444 (talk) 14:02, 27 October 2017 (UTC) Trying to say 'sorry if I offended you' while addressing me with 'Dude' — incomprehensible reply. This does not indicate you know what you say 'sorry' for, nor indicates improved behaviour. Please reconsider your attitude and rewrite using CIVIL and NPA for starters. -DePiep (talk) 14:42, 27 October 2017 (UTC)

• Why Respell should be kept, being usefull information. Per MOS, Respell is correctly added: "The Wikipedia respelling system, using the {{Respell}} template, can be used in addition to the IPA." I found no consensus to remove Respell altogether on any relevant talkpage, and no special case for the chemical elements has been made here or elsewhere: the elements are not an exception. Even better: by placing the pronunciation in the infobox, the first sentence is freed from the clutter(-argument).

Respell next to IPA actually does add information. While basically IPA and Respell, by intention, represent the same information of course, their appearance together is not redundant. Even the fact that this common background can be found through extra research (opening links, read Help, translations/transcriptions, sometimes mousehovering, manual re-composing), this does not make equivalency (redundancy) between their presence.

The fundamental differences between IPA and Respell are that IPA is neither in English language, nor in English script (Latin alphabet). OTOH, Respell is way close to natural English reading and is associating with English pronunciation off the bat. For example, it uses Latin alphabet, syllables, and intuitive stress notation.

Since the Readers of the English Wikipedia, well, read English by definition, IPA is not serving them. Very few enwiki readers can use IPA, that is: read and pronounce from it. But because of its close association with English, Respell serves almost all our readers. Removing respell would deprive virtually all these readers from their information. -DePiep (talk) 16:55, 7 November 2017 (UTC)

• In the #Respell section, referred to iby the RfC opening here, KDS4444 states: I don't think that any English speaker needs guidance on ...". This is not a relevant reasoning. The problem in the quote is, that the English Wikipedia is not written for 'English speakers'. And it introduces a strange circular reasoning: like: "We don't need a pronunuciation guide, because an English [native?] speaker already knows how to pronounce it". And non-English speakers (who are Readers too) are not served at all by this approach. Point is: We need to serve non-IPA readers. -DePiep (talk) 17:18, 7 November 2017 (UTC)

• RE IPA is fine as stated by John, I refer to my point above that IPA is neither English language based (it is international/language-independent), and not in the English alphabet. So most or our Readers are left behind. -DePiep (talk) 17:18, 7 November 2017 (UTC)
  • I think you underestimate the number of English dictionaries which use the IPA for their pronunciation key and no respelling. Outside America, pretty much all of them are like that (I just grabbed a few off my shelf), and it is not a stretch to say that the majority can read it. And that includes dictionaries meant for foreign learners of English, who often have IPA as the dominant pronunciation key for their own language as well. The major exception is America, but given that (1) mousing over the symbols gives equivalents referring to familiar English words, and (2) clicking on it leads to a complete key just as you will find in most non-American dictionaries, I submit that it is not a problem.
  • The problem with the respelling key is how it cannot isolate sounds like the IPA mouseover key, which hurts really badly when these sounds get respelled coincidentally to differently pronounced English works. In other words, as long as the respell keeps messing up cobalt, I think it is doing more harm than good. Double sharp (talk) 06:32, 8 November 2017 (UTC)

• I'm not making estimations about dictionaries. I'm claiming that the vast majority of our Readers can not use IPA (use IPA = speak from reading). Mousehovering to check each single letter pronunciation is tertiary info at best. Should the reader scribble down these IPA-to-en translated letters?

As for cobalt: add "(approx.)" I suggest. -DePiep (talk) 11:12, 9 November 2017 (UTC)

• A number of previous posts indicate that it is unclear what this RfC is asking, and I tend to agree with this. Consequently, I find that I cannot weigh in with a !vote because I don't know what my !vote would mean. And I submit that this lack of clarity will mean that should a consensus be declared, it will be of doubtful usefulness. I suggest that someone with a more solid grasp of what is intended close this one as "no consensus" and start a new one that is more clear. YBG (talk) 07:16, 8 November 2017 (UTC)

Discussion, arbitrary break (more about cobalt & gold)

May I, as a non-native speaker, step in.

If respell messes up cobalt, that is, of course, bad. (Could you fix it, though?) But that cannot be the reason to remove the respell. I've tried to look at gold as an example of a word that everyone agrees to be fairly simple. First of all, it appears (please correct me if I'm wrong) that the IPA pron and the respell produce different results, don't they? IPA is showing what I was once taught was called an "open syllable," while the respell clearly shows a "closed" one. Well, I decided to go check dictionaries. I picked two major ones (Merriam-Webster, Oxford), and they shows different IPA prons! Of course, there are differences between AmE and BrE, but the word is seemingly too simple for any differences to chip in. But even if it isn't, even more interesting is that neither is the IPA that we have. We can't use that as a rationale to remove the IPA key, so we can't call such a reason for removal of the respell template. (Please don't: it was Wikipedia that taught me that lead the chemical element was pronounced differently than the verb "to lead.")

Also, respell is easier to look at to just check the word. When in doubt, I have always used it and not the IPA because it's easier to read the information than to wait for mouseovers that I can't even use on my smartphone.--R8R (talk) 06:41, 9 November 2017 (UTC)

Regarding "gold", both dictionaries are agreeing that it has the vowel of "goat", but not on how to transcribe it (oʊ or əʊ). The main problem with "cobalt" is that the respell gives "bolt" for the second syllable, and that happens to be an English word with irregular pronunciation for its spelling, causing confusion. So I think we would need to do it at least with a parenthesised comment about the vowel. Double sharp (talk) 04:30, 28 November 2017 (UTC)

Please no space-consuming parenthesized comments in the infobox as long as possible. We can always use notes instead.

So M-W, Oxford, and Wiki all give the same pronunciation for "gold" despite different transcriptions? That's interesting. (If I get it right, oʊ vs. əʊ is AmE vs. BrE. Don't know if ō is the same.)

Can we agree that a sizeable share of our readers, even those among native speakers (remember, some native speakers confuse "it's" and "its" and make other silly mistakes), would not be immediately able to read IPA given these complications and would find that respell is easier to use? If so, what is the good reason not to provide them such an opportunity while keeping IPA for English majors?--R8R (talk) 14:55, 28 November 2017 (UTC)

Is there a solution for the cobalt? YBG (talk) 15:36, 28 November 2017 (UTC)

When we agree cobalt is an incidental issue, it should be handled separate from the RfC. Split into new == section? -DePiep (talk) 16:26, 28 November 2017 (UTC)

It is related. If there is no solution to the cobalt issue, then I think respell is a non-starter IMO. If there are multiple solutions, then which solution is chosen could be deferred until later. My question stands: is there any solution to the cobalt problem? I don't really care at this point to know the details of what the potential solution is, I just want to know that there is such a solution that the editors in this project could implement. YBG (talk) 17:50, 28 November 2017 (UTC)

Yes it is related, but no it is not part of this RfC. If cobalt has no good option, by exception that one Respell could be removed. I don't see how that would imply all Respells must be removed. We are not to be taken hostage. -DePiep (talk) 18:38, 28 November 2017 (UTC)

Okay, let me respond one at a time:

@R8R: Yes, oʊ vs əʊ is AmE vs BrE, from what I understand. (If you want to know what we say in BrE, we don't start rounding our lips until the vowel has glided away to "ʊ".) But it is a consistent difference: everything with oʊ in AmE has əʊ in BrE and vice versa, so in a certain sense it is the same, and you can just read it according to your dialect. O with macron is not IPA, but an American respelling system.

I think the main trouble with respell is that it is currently being conceived as a one-to-one replacement for IPA. This is why R8R has raised a problem with gold. It used to be respelt "GOHLD", which to me (and I guess to him) suggests the vowel of "law". So now he changed it to "GOULD", which suggests the right pronunciation. Except that it isn't canonical respell because we defined "OH" to always mean IPA oʊ, and the problem is that English spelling conventions are inconsistent and this will often give the wrong idea. At least here there is a reasonable out, though. I think we have to move away from the idea that respell is a one-to-one replacement for IPA for it to be more useful, as seen here, and spell things in a way that would be more consistent with English spelling conventions. As R8R has demonstrated, this is likely possible to do for everything but "cobalt" so far.

I'm inclined to agree with DePiep, since apparently the IPA is not as often used as I thought (could be a cultural thing, it's distinctly more common in some English-speaking countries than others). We should then keep the respell, perhaps fixed like R8R just did for Au. So the one problem is cobalt. Now I realise this breaks the key, but since R8R has already broken it to mke it more useful, how does "KOH-bollt" work for AmE speakers? It seems to work in BrE (suggesting the vowel of doll). Double sharp (talk) 04:12, 30 November 2017 (UTC)

Actually, what's really needed is a radio button thingy to allow the users to choose between IPA and respelling, like the options in |pushpin_map= in {{infobox settlement}}, as shown in Salem, Oregon. But I suppose that is overkill.

As far as "KOH-bollt" goes, I doesn't work for me; I'm pretty sure that the "oll" in "doll" is only pronounced that way when it is at the end of a syllable or maybe even only at the end of a word. What about "KOH-balt"? YBG (talk) 05:18, 30 November 2017 (UTC)

I urge everybody who has an issue with such respelling as KOH-bolt or GOHLD to take a look at WP:PRON for crying out loud. The whole point of a respelling is that every letter (or every combination of letters) used is defined at the H:RESPELL key so that it would be consistent. There are possibly hundreds of monosyllabic words that disagree with the key, but if we had to improvise at every turn, the consistency would be lost and the key―and therefore the respelling as a whole―would be rendered useless.

There is no ambiguity in KOH-bolt or GOHLD, unless one is too lazy to click on the respellings. Yes, there is the word bolt /boʊlt/, but that would be respelled BOHLT, because o is defined as the vowel in lot and oh is defined as the vowel in boat. GOULD for gold is just bonkers, because not only is it susceptible to being interpreted as /ɡaʊld/ GOWLD but also there's the proper name Gould, which is pronounced /ɡuːld/ GOOLD! And who in the world pronounces a word spelled with oh with /ɔː/? That vowel is respelled aw, as in law, paw, lawn, etc. /oʊ/, the vowel of gold, is exactly the sound of the interjection oh, so why use anything else when oh is literally the least confusing combination of letters to represent the sound?

But as you can see, the respelling has its limitations because English orthography is just too inconsistent. Especially sounds such as /ʊ/ as in foot (respelled uu) and /aʊ/ as in mouth (respelled ow) are just too difficult to represent using the usual English spellings (can you think of any way to represent them using no diacritic that could not possibly be confused with /uː/, /ʌ/, /oʊ/, or /ɔː/?). That is exactly why WP:PRON prescribes IPA as a must, while respelling as optional. So we can just get rid of the respelling whenever it's not helpful, and leave the IPA.

It should also be noted that our IPA and respelling systems are meant to cover multiple varieties of English (called diaphonemic; detailed at Help:IPA/English § Dialect variation). /oʊ/ in our Help:IPA/English system is defined just as the vowel in boat, regardless of how it's actually pronounced in one's accent. In fact, that is how the notations in dictionaries are defined, rather than transcribing a word exactly the way it was said by one particular speaker one particular time: [4][5] (a practice called phonemic transcription, indicated by /slashes/ rather than [brackets]―see International Phonetic Alphabet § Types of transcription), though they typically pick one representative accent (such as Received Pronunciation or General American) unlike ours. So /əʊ/ seen in British dictionaries and \ō\ seen in American dictionaries represent the exact same thing as what we mean by /oʊ/. The notation used by Merriam-Webster is not even IPA-based, by the way: [6].

As I (and others) have stated above, WP:PRON and WP:LEAD already prescribe:

1. no pronunciation notations for common English words;
2. use IPA for words difficult to pronounce;
3. a respelling may accompany the IPA, but not necessarily;
4. a respelling cannot stand on its own, must follow an IPA notation.

And I don't see any reason whatsoever to go in another direction here. Nardog (talk) 07:21, 30 November 2017 (UTC)

Thank you for your comment.

I could not think that "oh" was actually representing two vowel sounds. Perhaps they best way would be to change it would be to agree that "ou" should be the respelling for that. That, of course, would require a separate discussion with phonology Wikipedians.

The possibility of keeping the respell and removing the IPA is not seriously considered. The consensus on the previous section, as you can see, is to have both except for simple words, which may have neither.--R8R (talk) 10:59, 30 November 2017 (UTC)

Neither of /oʊ, eɪ, aɪ, aʊ, ɔɪ/ are two sounds. /oʊ/ is typically a transition from one quality of a vowel to another but cannot be separated into two segments, so it's usually considered to be one phoneme; see Diphthong. (In fact, it is pronounced like a single sound in certain varieties of English, so a Southern British pronunciation of law might sound like low to Scottish ears.)

And ⟨ou⟩ most often represents /aʊ/ (as in out, loud, house) or /uː/ (as in you, soup, group), so I'm having a hard time imagining "phonology Wikipedians" approving of it to represent /oʊ/. Nardog (talk) 11:40, 30 November 2017 (UTC)

Technical note: recently I moved the pronunciation data from individual infoboxes into a central data set (see #below). You may want to follow those 6 datapages for edits. (I just applied R8R's GOHLD change there). -DePiep (talk) 11:55, 30 November 2017 (UTC)

Thank you for this explanation. However, I've checked diphthong and it says that a diphthong "is a combination of two adjacent vowel sounds within the same syllable". "Oh" certainly misleads me as it not only may not accurately represent my expectations (I understand the limitations of the English alphabet), but also does not correctly display the number of vowel sounds in a word. And then again, I am open to alternative suggestions.--R8R (talk) 12:09, 30 November 2017 (UTC)

That wouldn't be a problem so long as one has a grasp of what a syllable in English is. The respelling is specifically designed to be "intuitive" for native speakers of English because English speakers, particularly Americans, just don't have enough opportunities to get exposed to IPA. If you're a non-native speaker, and especially if you don't have a complete grasp of how certain letter combinations are expected to be pronounced in English (Phonics is the term), I suspect learning the IPA key is the shorter route than to learn the respelling from the start, because the IPA has greater correspondence between symbols and the sounds they represent, and thus is perhaps more intuitive for someone who speaks another language as their first language (I'm such a person). Nardog (talk) 12:32, 30 November 2017 (UTC)

I had been taught IPA since the age of four until I was twelve. I may have forgotten quite a lot, but as this discussion unfolds and I read your replies and check information myself, the knowledge is recovering.

I understand the point of respell; I have seen it as such since I saw the respell. What bothers me is that "oh" is a closed syllable. I cannot imagine anyone thinking that "OH" is an actually good substitute for /oʊ/ rather than what we have to use in an absence of alternatives. Intuitively, I think that the best option would be to use "O^U," but I am not confident if superscript letters are okay.--R8R (talk) 12:54, 30 November 2017 (UTC)

I might add that I highly doubt the average reader is going to click to the respelling key. I think that for the most part, they're going to assume that since it looks like English, it should be read like English, and mess up "cobalt" if they don't already know how to pronounce it. At least IPA would force most of them to click or at least mouseover, which would stop them from getting the wrong idea from a respelling. Double sharp (talk) 14:19, 30 November 2017 (UTC)

I strongly object to this approach by Double sharp. See #re 14:19 below. -DePiep (talk) 10:58, 2 December 2017 (UTC)

To make it clear, having IPA alone is not a great solution, either. I would rather ignore the IPA not bothering to try to read it thinking that I know how English words are pronounced and the bother to read IPA is not justified. The bother to read respell is not as high, so I could give it a try.

But I'm beginning to get the idea that if a respell cannot be obviously pronounced and there is no correct and obvious letter construct for /oʊ/ ("'oh' is defined as /oʊ/ is worse than '/oʊ/' because at least we could expect we'd have to pay attention here), we could have to abandon it for such words (and them only). Another question, though: how would you pronounce "goald"?--R8R (talk) 14:38, 30 November 2017 (UTC)

I would define "OH" as an open syllable phonetically; that is to say, I see it as an open syllable that happens to be spelled with a silent letter. And as for "goald": "goal" by itself is for the en-5 speaker is easily pronounced, because "oa" followed b a single consonant has a very consistent pronunciation. But "oa", I believe, almost never appears with two following consonants. The problem with most respellings is that they try to take an IPA-like one-grapheme-per-one-phoneme approach, but natural English spelling is more complicated than that. A vowel quality depends not only on what vowels are used to spell it, but also on its position in the word, especially, what syllable it is and what letters appear after it. umRespelling gets around some of this by separating the syllables in order to "turn off" the multi-syllable pronunciation rules, but to work well, a respelling system needs to abide by English syllable spelling rules. I was an adult before I came to realize that English spelling is unjustly maligned - yes, there are a few true exceptions, but the vast majority of English words can be sounded out correctly by those who have internalized the rules of English pronunciation. English spelling and pronunciation rules are indeed complicated, but far less irregular than most people think. But that is another story and far outside the subject matter of this project </rant>. YBG (talk) 16:03, 30 November 2017 (UTC)

@YBG: Have you seen zompist's exposé of English spelling? ^_-☆ Double sharp (talk) 09:21, 2 December 2017 (UTC)

The problem is that the current "gohld" is not pronounced like "gold." I've tried to remember words with "oa" that I know: coal, goal, loaf, etc., and all of them did indeed correspond to the /oʊ/ sounds. Can you think of an example when this grapheme (what a word) is pronounced differently? If not, then it's a strong candidate to replace "oh," which is not intuitively /oʊ/ whether it is open or closed. Yes, "goald" is a respell would look a little odd but that's quite often the case with respells. Most important is that it is correct.

P.S. English is sometimes odd but beautiful in its oddity ♥♥♥ Also, learning a second foreign language did give me a broader perspective on English.--R8R (talk) 16:21, 30 November 2017 (UTC)

English oa indeed seems to be always long o, except if it crosses a morpheme boundary (e.g. coaxial). Double sharp (talk) 09:37, 2 December 2017 (UTC)

I've been hinted that this is not the case when "oa" assumes the final position (goa, boa, etc.)--R8R (talk) 10:25, 2 December 2017 (UTC)

@Nardog: I think the problem with using "oh" for long o for chemical elements is that the one time it occurs, it is in bohrium, which has the vowel of law. You could certainly argue that that is a borrowing, but given that non-final oh itself is something rarely seen outside borrowings, it strikes me that it is not so helpful either (e.g. Ohm vs. Bohr). Which is why I still think that if you want to get matters of pronunciation right, especially for a language which has sounds not found in your native one, learning IPA and some basic linguistics is still the best way to go (I mean, that's how I was taught to deal with French r, for example, though I still rather old-fashionedly say it as a trill instead of a fricative). But it seems evident that I am not in the majority here.

P.S. I think some of the synthetic elements may not quite be completely assimilated to English anyway. I pronounce Roentgen and roentgenium with the German o-umlaut, after all. Double sharp (talk) 06:03, 4 December 2017 (UTC)

re 14:19 Double sharp, 'I might add ... '. This is making assumptions about readers I find not convincing. And even when having a base, these are not statements we should guide us. I doubt; average reader; they assume; mess up; force them: this is not how wikipedia works. Of course, taking the exception of cobalt as an example for all is bad arguing. Then, forcing readers to study IPA (or else ...) is bad quality, while the more obvious and intuitive solution is already in there: use respell. Sure non-native speakers can mess up, but that is only prevented with a thorough knowledge of IPA. An incomplete knowledge of IPA can mess things up just as well. Finally, if this approach would be sound and useful, it should be applied to all respell usage (it is not specific for elements). Take it to WT:PRON? -DePiep (talk) 10:58, 2 December 2017 (UTC)

@Double sharp: I highly doubt the average reader is going to click to the respelling key. I agree. The solution to a case in which a repselling could be misconstrued, however, is to encourage them to click on it (or simply remove it), not to tinker with it, which would only jeopardize the consistency and reliability of respellings across Wikipedia as a whole. Nardog (talk) 13:06, 8 December 2017 (UTC)

re Nardog @ 07:21 ("I urge everybody ..."). Thanks for this comprehensive overview. It appears that both our IPA and respell writing is strongly guided or defined.

First, about respelling cobalt where you conclude to get rid of the respelling whenever it's not helpful, and leave the IPA. I understand, but what about this option: add "approximation: KOH-bolt"? For a non-IPA reader this is helpful, getting the stressed syllable right in the for starters.

Second, you list the guidelines 1–4. Only 3. a respelling may accompany the IPA, but not necessarily; is contentuous here. Actually, that and only that is the original RfC question: "remove all respellings from the 121 infoboxes". Wrt this, as I read it, people here do not support such blanket removal, either by direct !vote or implicitly by proposing an alternative approach. So already, IMO, the simple conclusion for this RfC should be: "no". But we can improve upon this, without breaking any guideline. That is: add respelling with IPA for each pronunciation, to add helpful consistency and over these infoboxes (cobalt excepted). Unfortunately, your conclusion wrt this guidelines, [not go] in another direction, does not address this. -DePiep (talk) 10:36, 2 December 2017 (UTC)

@DePiep: what about this option: add "approximation: KOH-bolt"? No, because KOH-bolt is NOT an approximation. Rather, it is a reiteration of the preceding IPA notation in a more widely accessible format using only the English alphabet letters (and ⟨ə⟩), exactly as defined at the H:RESPELL key.

add respelling with IPA for each pronunciation, to add helpful consistency and over these infoboxes (cobalt excepted). I'm afraid I don't quite understand what exactly you're suggesting. As soon as we uniformly add or remove all respellings from element articles, or uniformly add pronunciations (either just IPA or IPA+respell) in all elements' infoboxes including common words such as gold, we're already diverging from WP:PRON. And let's not do that and stick to WP:PRON, namely the four points I named above. Nardog (talk) 13:06, 8 December 2017 (UTC).

@Nardog:, cobalt. OK then. This is my irritation with the cobalt here. As I understand it, Double sharp argues that cobalt can not be written in {{Respell}}, because its sound is not available in Respell transcription (defined in H:RESPELL as you explained). So far all fine, though I like to hear from you if you agree with Double sharp in this point. I myself cannot judge that. A sound conclusion then would be that for this reason, {{Respell}} pronunciation should be removed from Cobalt. I could agree with that, if only it were clearly proposed by Double sharp and/or you. I note that this is a "how to respell" issue, outside of this RfC.

Trouble starts when Double sharp then makes the consequence that all {{Respell}}s should be removed from this infobox (as was the original RfC question). I do not agree with this logic at all. IMO it is this confusion is one that holds a consensus for this RfC.

re "don't quite understand": I can understand ;-). No one is proposing to deviate from WP:PRON, or the four guidances you listed above. No one. First: the RfC asks if the Respell part of a pronunciation pair should be removed for all infoboxes. OTOH I propose to add that everywhere when there is an IPA (except for cobalt for reason just mentioned). This remove/add/keep a respell does not break WP:PRON in any way. It is about guidance #3 (!) you listed at 07:21: respell is nor required nor forbidden, so what do wi do with that? (here too I like to hear your opinion).

Yes I know that common English words like gold should not be IPA'ed. But that is not the question here. Even worse, IMO the hammering on this undisputed point is distracting and hindering a sound conclusion for this RfC. -DePiep (talk) 10:41, 12 December 2017 (UTC)

The sound of cobalt can be written by taking respell as a one-to-one replacement of IPA. However it results in things like "bolt" appearing, which suggest the wrong thing to the reader unless he clicks to the key. But if the reader is going to have to click to the key anyway, why not just use IPA to begin with? At least it suggests immediately that it shouldn't be read like the English word "bolt". Double sharp (talk) 14:05, 13 December 2017 (UTC)

Finally I am seeing your point :-). To this, I can say: it is up to the reader to mess up respell (by not following/using/knowing the H:RESPELL definitions). As the reader can mess with IPA. And the reader can mess with any wikilink. Example: if I see a link to a country Tuva, and I assume it must be in Spanish South-America, that's my own fault or sloppyness. Wikipedia has no task in preventing this stupidness. IOW, if a reader misunderstands the spelling "-bolt" for cobalt, that is no fault on the Wikipedia side. (I understand that, as Nardog clarified that the HELP:RESPELL list is defined and so can not create incidental new spellings, this route for cobalt is not open any more). -DePiep (talk) 10:38, 14 December 2017 (UTC)

Yeah, but our particular respell key isn't exactly standard anywhere outside Wikipedia, so I'm not sure it makes sense to fault the reader for not knowing it, especially since it looks familiar enough that she could reasonably assume that she already does. Whereas the IPA is standard and at one look you already can tell whether you know it (in which case, good for you) or you don't (in which case you immediately know you have to click or mouseover for the key). Double sharp (talk) 01:28, 15 December 2017 (UTC)

Double sharp Well, I was not putting a reader at fault except myself as an example ;-). I meant to say: if a reader does not know, or look up, a key or linked article, that's their choice and risk of getting it wrong. And yes, it may be an enwiki-only respell key, but that can be said for all dictionaries. Finally, again, yours is an argument to remove all respell from this wiki, and with Nardog (see below) I say that this can not be decided (not even with consensus) in this local place. It is legal to add Respell per WP:PRON. -DePiep (talk) 09:41, 15 December 2017 (UTC)

Yeah, but there is not much indication that one needs a key at all, especially since the point of respell is to make the pronunciation intuitive to those who can't fluently read IPA (though I am not sure how the average reader interprets the schwa letter ə). In most cases it is all right, as the pronunciation suggested is the correct one, and there I don't have a problem with its inclusion: the information is presented multiple times, but correctly each time. It's only in the actively misleading cases like cobalt that I would argue in favour of removing the respelling and using only IPA. IPA really does things a lot better than ad hoc respelling procedures, that always don't work for every word because of the vagaries of English spelling, and that is why (at least outside the US) it is the standard way in which dictionaries indicate pronunciation (yes, with a key in the back). And to my thinking, while I am fine with having two correct ways to indicate pronunciation, if I have to choose between one correct and one incorrect way and just one correct way, I'll pick the latter, even if it's more unfamiliar to some readers. Double sharp (talk) 15:18, 15 December 2017 (UTC)

@DePiep: This remove/add/keep a respell does not break WP:PRON in any way. It does, at the moment we mandate or ban respellings for all IPA notations for elements. What WP:PRON says is that respelling is optional, which means that anyone can boldly add or remove a respelling, or revert such an edit and launch WP:BRD, in any article on any subject. Nardog (talk) 23:52, 14 December 2017 (UTC)

re "would we break WP:PRON?": no, if consensus would say to remove/add/leave respells, all is within the PRON rules. Moot. -DePiep (talk) 23:37, 14 December 2017 (UTC)

if consensus would say to remove/add/leave respells, all is within the PRON rules. Only if we removed or added all at once and didn't bother someone undoing them. But what's the point of it if it wasn't made into a rule? And as soon as we make it into a rule, we've made an exception to WP:PRON. Nardog (talk) 00:03, 15 December 2017 (UTC)

I had the impression that we here could reach consensus to remove all for these infoboxes, as rule #3 allowed that. And after all, that was the original RfC question. Now I could happily agree with you that "we are not allowed to make this local exception rule to WP:PRON" [not even by consensus then], because that serves my wish (do not blanket remove all). Unless this pops up elsewhere, we could leave this alone I guess. -DePiep (talk) 00:53, 15 December 2017 (UTC)

The respells are for the most part OK with me. Only in a few cases, like cobalt, do I think that the respell should be removed as misleading. Double sharp (talk) 01:28, 15 December 2017 (UTC)

@Double sharp: So I suppose your answers to the questions I asked below are "no" and "no". Is this assessment correct? Nardog (talk) 11:46, 19 December 2017 (UTC)

@Nardog: Yes. Double sharp (talk) 12:08, 19 December 2017 (UTC)

• wiktionary:cobalt#English says:

(UK) /ˈkəʊ.bɒlt/

Audio (US)^ⓘ

Shall we add the IPA US? And the audio? (note the diff /oʊ/ vs. /əʊ/ used for UK). -DePiep (talk) 11:24, 2 December 2017 (UTC)

@DePiep: No. Please see WP:RHOTIC. Nardog (talk) 13:06, 8 December 2017 (UTC)

OK, so WP:RHOTIC says, like: do not use UK/US as separate pronunciations. Next question(s): shouldn't the "(UK)" be removed then? And: cannot we add the available US-pronunciation to the UK-IPA (all within WP:RHOTIC understanding)? Especially since cobalt can be confusing, the audio may be helpful. -DePiep (talk) 10:26, 14 December 2017 (UTC)

WP:RHOTIC doesn't apply on Wiktionary. Wiktionary uses a more detailed transcription system for English because it's a dictionary, which Wikipedia is WP:NOT.

We can add File:En-us-cobalt.ogg to /ˈkoʊbɒlt/ on Wikipedia, sure ({{IPAc-en}} covers multiple accents so we could add an audio to it whether the speaker has a UK or US accent). That would be a lot more helpful to readers than KOH-bolt, I suppose. Nardog (talk) 23:07, 14 December 2017 (UTC)

Actually, WP:RHOTIC isn't really relevant in this case because /oʊ/ and /əʊ/ are essentially the same vowel ("the GOAT vowel"), of which only the quality differs in General American and Received Pronunciation, not the distribution. So I guess I should have just repeated what I said above (see the paragraph "It should also be noted..."). Nardog (talk) 23:40, 14 December 2017 (UTC)

(Not to spend too much time on this, but ...) I get that these two pronunciations are different (even when generalised in IPA as described, not tied to a specific person speaking), but they are not different enough to list them here as different. OK. With this, my suggestion was and is: add the available audio (an US one), and do not mention any "US/UK" specifier. Or would that be an unhelpful stretched (reversed) use of the IPA guidances you mention? -DePiep (talk) 09:26, 15 December 2017 (UTC)

would that be an unhelpful... No, like I said: {{IPAc-en}} covers multiple accents so we could add an audio to it whether the speaker has a UK or US accent.

In other words, I support your suggestion. It's already practiced in hundreds of articles. Nardog (talk) 11:46, 19 December 2017 (UTC)

Discussion, arbitrary break: back to the original question

moved from above

So let's confirm this: @DePiep, Double sharp, R8R, and YBG: Do any of you think we should have respellings next to all existing IPA notations for elements, or that we should remove all existing respellings in element infoboxes? My answers are "no" and "no". Nardog (talk) 23:07, 14 December 2017 (UTC)

• 1. There is no consensus to remove all Respells (and I don't want it). 2. I want all IPA's to have a respell, especially since I've read no true objections to this. Cobalt could claim individual exception, pending detail discussion. -DePiep (talk) 23:37, 14 December 2017 (UTC)

Cobalt could claim individual exception Then that's not all. I specifically said "all" for a reason. You say that because KOH-bolt may be unhelpful or confusing, not because cobalt has another special reason to be treated differently, right?

So to rephrase my first question: Would you support making it mandatory for any IPA notation for an element to be accompanied by a respelling, without any exception? I suppose your answer would be "no".

Imagine an element was discovered and named sonium /ˈsɒniəm/. To include the repselling SON-ee-əm would not be ideal because most readers are likely to read it as /ˈsʌniəm/ because there's already the word son, pronounced /sʌn/ SUN. SO-nee-əm is another option, but that also is more likely to be interpreted as /ˈsoʊniəm/. So having a respelling for this hypothetical element is not desired, and thus we wouldn't want to make it mandatory for any IPA notation for an element to be accompanied by a respelling.

This is what I was getting at by asking people whether "we should have respellings next to all existing IPA notations for elements". Nardog (talk) 12:03, 19 December 2017 (UTC)

re Cobalt may require an exception. That should be discussed and concluded in the section above, which is dedicated to that topic. I blame you for muddying this restart question(s) by introducing the cobalt incident *here*. One can not discuss in two places, full stop. I wrote "exception" for a reason.

No do not rephrase the question into a "mandatory", don't limit the RfC to a stone-engraved "all". Clearly: I want every IPA present in these elements to have a respell, by choice, as RfC result. Because the guidelines etc. allow so, it helps many many readers, and because I have not read a single argument on why to remove Respell when it's IPA is present. Not one. -DePiep (talk) 17:51, 19 December 2017 (UTC)

I italicized "all" because I meant a stone-engraved "all", and that's exactly what I'm trying to persuade us away from, which you seem to be as well.

The questions above are essentially a paraphrase of "Should we deviate from WP:PRON?", for which none has explicitly advocated as far as I can see. Nardog (talk) 18:18, 19 December 2017 (UTC)

• I am not in favor of (1) including IPA for all elements or (2) excluding IPA for all elements or (3) including RESPELL for all elements. But I might be convinced to (4) exclude RESPELL for all elements - indeed everywhere in WP - or better still to reform it. If I understand correctly, RESPELL attempts to duplicate the IPA pronunciation with a transformation of each IPA symbol to one or more English letters consistently, which I think is a fools errand and will definitely cause misunderstanding. If you're going to use English letters, then they should conform to English pronunciation rules, where a vowel can be pronounced differently depending on the number and characteristics of the consonants that close the syllable. But reforming RESPELL is completely outside the scope of WP:ELEM. YBG (talk) 23:47, 14 December 2017 (UTC)

  Only your reply (3) refers to the question. (1) and (2) are off-topic. (4) is about WP:RESPELL in general, and so this is not the right place. -DePiep (talk) 00:14, 15 December 2017 (UTC)

  OK, (1) and (2) are off-topic. But I believe my (4) is on topic - or at least the first five words of it are before I got carried away with an issue that I admitted "is completely outside the scope of WP:ELEM." YBG (talk) 00:31, 15 December 2017 (UTC)

  Fair enough, but your (4) argument is referring to the whole Wikipedia respell setup, and so can not be decided here. We cannot change WP:PRON rule #3 here ("Respell may be used"). Also, I don't think we should accept a wedge argument (like "I dislike it everywhere, let's start removing it here"). -DePiep (talk) 09:09, 15 December 2017 (UTC)

• Please, R8R, reply here. -DePiep (talk) 20:12, 15 December 2017 (UTC)
• Please, Double sharp, reply here. -DePiep (talk) 20:12, 15 December 2017 (UTC)
• It appears there is already a certain consensus to keep close to what we have, except users have spoken in favor of not including IPA for some common words. I support that. In general, I do think that our respell is a nice accompaniment to the IPA and would want to keep it. Correct me if I'm wrong but it seems from this discussion that it does some fine jobs in respelling all (but maybe one) stable elements. As I've seen in the archives of the phoneticians, "cobalt" is generally a word that gave them some trouble. It appears that of all elements, it may be an exception, maybe the situation is even worth an explanatory note in the infobox, since notes are cheap to add. It's certainly something I'd do if I was writing that article. The remaining element respells are apparently fine. Even though I was wrong with "oh," this is not going to be a common mistake.

Long story short: keep respells alongside IPA, abandon both respells and IPA for common words (iron, silver, etc.). Of all common words, I would prefer to keep them for lead, though, since it has an homograph of a different pronunciation.--R8R (talk) 21:11, 15 December 2017 (UTC)

@R8R: You didn't answer my first question very clearly. Would you say we should "keep respells alongside IPA" with no exception, even for cobalt etc. where respellings may not be of as much help as they are in most other elements? Nardog (talk) 13:18, 19 December 2017 (UTC)

Errrm, Nardog, this is not what your first question asks. The "... where respellings may not [be] of ..." is not in there (and actually was not discussed at all along the route). Also, engraving cobalt as a non-exception into stone is new. PLease rephrase, following the original RfC. -DePiep (talk) 17:27, 19 December 2017 (UTC)

Fair enough. But why else would one not have a respelling besides because it may not be helpful? Nardog (talk) 18:18, 19 December 2017 (UTC)

• Note @Nardog, Double sharp, R8R, and YBG: I have opened a new discussion here to take that one "common English" issue out of this RfC for good (it was never in). -DePiep (talk) 12:31, 18 December 2017 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.