Template talk:Respell/Archive 1

Note

Note: To check for errors, try running an AWB list-compare of transclusions of template:respell vs template:smallcaps all [or whatever we're using for stress], and skim the articles that only transclude the former. Very few articles (such as February) legitimately use this template w/o any indication of stress.

Suggested change to documentation subpage

Since the pronunciation respelling key is only for English words, Strasbourg is probably not the best example. Maybe a city with a startling pronunciation from the English-speaking world, like Cholmondeley or Natchitoches, would be better. —Angr 13:08, 6 October 2008 (UTC)

 Done. — Cheers, Truth's Out There ^–talk– 08:50, 7 October 2008 (UTC)

The example you picked illustrates well the dubiousness of using small caps to indicate stress: WOOS hardly looks like it's in small caps at all; it's barely distinct from woos, at least in the font I'm using (Arial, which is probably the font most users, especially those who aren't logged in, are seeing too). —Angr 09:50, 7 October 2008 (UTC)

I didn't know about this template ({{respelled}}), and so made my own: {{respell}}. It makes alternating cells smaller, so if you type them in caps you get fake small caps. They're not as small as the ones here, and so are more salient. Maybe we could merge them? (I have no 'pronounced' option, as this should not be the first transcription for anything.) kwami (talk) 10:11, 20 December 2008 (UTC)

Yes, go ahead and merge the two templates, although I can't really spot the difference in size between the small caps in {{Respelled}} and {{Respell}}. — Cheers, Truth's Out There ^–talk– 03:59, 22 December 2008 (UTC)

Okay, done. Of course, you can continue to use manual formatting within a single cell, but the 'pronunciation' toggle no longer works. kwami (talk) 07:07, 22 December 2008 (UTC)

Display with sound file?

Is there a way to use this template (or one like it) for a pronunciation respelling followed by a sound file link? I recently added this to Dalek, which already had the IPA spelling and a sound file, and this is the result:

The Daleks (pronounced /ˈdɑːlɛks/ , DAH-leks) are...

I think it would look better if the sound file link were after the respelling instead of between the IPA and the respelling, but it doesn't look like this template has a link for that. I suppose I could use {{audio}}, but the display for that is bigger and clumsier:

The Daleks (pronounced /ˈdɑːlɛks/, DAH-leks, ) are...

Any suggestions? —Josiah Rowe (talk • contribs) 06:30, 14 April 2010 (UTC)

Comma between IPA & respelled

Does anyone else find that the suggested comma between IPA and respelling pronunciations looks bad? --Cybercobra (talk) 06:37, 14 July 2010 (UTC)

I've now raised the issue at the MoS: Wikipedia_talk:Manual_of_Style_(pronunciation)#Comma_between_IPA_.26_respelling_looks_bad --Cybercobra (talk) 21:24, 23 July 2010 (UTC)

I've removed such commas when I've come across them. — kwami (talk) 07:01, 11 May 2011 (UTC)

Now systematically removing them. I've probably missed a few where there were parentheses or other stuff like refs in between. But I've been leaving it along when it's parenthetical IPA (respell). — kwami (talk) 01:53, 12 May 2011 (UTC)

now accepts final stress

Just put an apostrophe in the final cell, and it won't display, shifting the stress to the end. — kwami (talk) 07:05, 11 May 2011 (UTC)

I've now converted all -<small>ABC</small>}} to |ABC|'}}, and am now working through changing -{{sm|abc}}}} to the same. I've figured out some neat AWB syntax for the latter, if anyone's interested. (This is new to me, so I'm interested!) I'm not saying this is elegant, but it works:

\{\{(sc|sm)\|([a-z]*) → {{$1|{{subst:uc:$2}} [check 'regex' box]

— kwami (talk) 22:57, 11 May 2011 (UTC)

Thank you! That's so much nicer and easier to read. – Kerαunoςcopia^◁_galaxies 03:02, 12 May 2011 (UTC)

Good. Chime in above if you like. — kwami (talk) 03:52, 12 May 2011 (UTC)

Bolding looks completely wrong

I just noticed this on the São Tomé and Príncipe, where the respelling seemed to be saying that the stress in Tomé was on the toh syllable. I went to correct it and found that the problem was actually with the template -- it bolds the toh syllable, and puts may in small caps.

Apparently this is supposed to indicate that the stress is on the may, but to me it comes out exactly backwards -- bolding looks more like stress than small caps do.

I think it would be fine if you just dropped the bolding entirely. If you want to make the point even clearer, make the stressed syllables both bold and small-caps, and the unstressed ones italic and minuscule. --Trovatore (talk) 00:08, 12 July 2010 (UTC)

I don't know what you're talking about. This template doesn't use any boldface at all. +Angr 05:52, 12 July 2010 (UTC)

OK, here's a screenshot of what I see, taken from the section above on this talk page:

Sorry about the PNG artifacts, but I think you can see that the leks syllable appears to be in a distinctly heavier typeface than the DAH. It makes me want to read it "dah-LEKS". This is in Firefox 3.0.19. --Trovatore (talk) 06:11, 12 July 2010 (UTC)

See User:Trovatore/Template:sandboxrespell, tested at User:Trovatore/testRespell. What I did was bold only the syllables intended to be small-caps. In my setup, that makes all syllables appear to have the same typeface, which is certainly more satisfactory than the existing situation. For people who already saw them in the same typeface, bolding the stressed syllables should make the stress even clearer, so I don't see that as a bad thing. What do you think? --Trovatore (talk) 07:01, 12 July 2010 (UTC)

The problem seems to be the way the font you're using renders small caps. It's true that the leks is much heavier than the DAH in your image, but it's no heavier than "The", "pronounced", "listen", or "are", and it's noticeably lighter than "Daleks". We can't force this template to put everything small-capped into bold, because WP:Pronunciation respelling key distinguishes between normal weight oo for the FOOT vowel and bold oo for the GOOSE vowel. +Angr 12:01, 12 July 2010 (UTC)

Not anymore. We could make them all bold. I'll put it in and see if we get complaints. — kwami (talk) 07:03, 11 May 2011 (UTC)

Yeah, that should work now that foot and goose are distinguished as FUUT and GOOS rather than FOOT and GOOS. If there are complaints now, they're liable to be that this system is supposed to be "intuitive" and there's nothing intuitive about uu for /ʊ/. —Angr (talk) 07:27, 11 May 2011 (UTC)

It looks much better with redundant bold for stress, though. — kwami (talk) 08:06, 11 May 2011 (UTC)

Thanks, I think this is an improvement. --Trovatore (talk) 22:07, 11 May 2011 (UTC)

I like the old style of small-caps for monosyllables, though. Cf. "boss" BOSS with "boss" BOSS. — kwami (talk) 23:32, 11 May 2011 (UTC)

I'm fairly indifferent to how monosyllables are displayed; their stress is determined by general rules of English depending on how they sit in the surrounding utterance. So either minuscule or small-caps, bolding or not, is fine with me. --Trovatore (talk) 00:29, 12 May 2011 (UTC)

(Ideally I think we'd use the {{sc}} template rather than <small> and bold, but if we did, people would loose track of which cells are going to display as stressed, resulting in an almost random mess. With the current setup, when we come across l.c. in bold small print and u.c. in large print, we at least know that s.o. messed up. — kwami (talk) 23:34, 11 May 2011 (UTC))

Would this actually be better?

1. IT-lee
2. {{respell2|IT|lee}}

The second version converts u.c. to l.c. and then formats it as small caps, which are larger than caps made small, and also in many fonts specially designed by the typographer for balance and weight:

1. SEER-eez
2. {{respell2|SEER|eez}}

Unfortunately, this way of doing it would mean that people could get away without using caps in the input:

{{respell2|seer|eez}}

which will lead to less obvious mistakes. — kwami (talk) 01:24, 12 May 2011 (UTC)

(my to-do: search A-Z}} w/o |'; search trans. w/o pipes.)

No, I don't like the version 2. It again comes out with the unstressed syllable looking heavier. --Trovatore (talk) 01:57, 12 May 2011 (UTC)

Really? Must be a difference in our fonts. With mine, #2 is balanced. In #1, the stressed syllables are too small and too dark, giving conflicting clues as to which syllables are stressed (the small, dark ones, or the large, light ones?). — kwami (talk) 01:59, 12 May 2011 (UTC)

Here's what I see: . --Trovatore (talk) 03:46, 12 May 2011 (UTC)

What about now? #2 is still true small caps, rather than reduced-size caps, but also bold as in #1. This way the stressed syllables aren't tiny on my screen, but hopefully they're not light on yours. — kwami (talk) 03:50, 12 May 2011 (UTC)

Yes, that seems fine. Now #1 and #2 are virtually indistinguishable for me. --Trovatore (talk) 03:53, 12 May 2011 (UTC)

Okay, switched over. — kwami (talk) 05:10, 12 May 2011 (UTC)

Arbitrary break

My timing was completely off here. I really liked it the way it was before. I actually wrote a mini-paragraph on why I liked the new version, I hit "submit" and walked away. When I came back half an hour later, I saw that I had an edit conflict with the "switched over" comment above. Too bad lol. What I had written doesn't really matter any more was that the small caps/non-bolded version was difficult to read. And this newest version isn't easy to read at all; it's a lot like the original version. When I posted my thanks below, that version, the bold and larger caps, was extremely easy to read and you didn't have to struggle. Small caps, caps smaller than regular letters, makes zero sense to me, and in my opinion slows down the reader quite a bit. Even with the bold. I prefer the bold-caps version (or whatever was being used in the previous version). I hope that all made sense. – Kerαunoςcopia^◁_galaxies 05:46, 12 May 2011 (UTC)

I'm not sure which version you're speaking of. In my browser, at least, the {{sc}} template makes bigger letters than <small></small> does. One of the problems I had with the old version was that the "big" letters were smaller than the "little" letters. Anyway, the way it is now, the size of the letters is determined by you, by which font you choose. The designer of your font specified how large small caps should be compared to l.c. The old way was rather arbitrary: "small" might mean any of a range of sizes. Though there's probably a way to control for that too, for me it would be easier simply to choose a font that I like for my browser. — kwami (talk) 05:54, 12 May 2011 (UTC)

Sorry, it was getting too confusing. Starting over, I prefer the "01:07, 11 May 2011" version of the template (you've only made one change since then). I copied the template that I preferred over to my sandbox. I prefer version 1: Example of both versions. I didn't read the whole discussion above, but apparently different browsers affect the outcome of the template? – Kerαunoςcopia^◁_galaxies 06:07, 12 May 2011 (UTC)

I've looked at this on a couple browsers. Either way, version 2 (current template) shows the caps letters as being smaller than the regular letters, which was also my issue with the original template. I just didn't think anything could be/would be done about it. Version 1 (on my sandbox) I think looks swell and is easy to read. – Kerαunoςcopia^◁_galaxies 06:22, 12 May 2011 (UTC)

What "small" means depends upon your browser settings. Most people just leave it at the default. It will interact unpredictably with different fonts. If "small" means a reduction in size of x%, then if you use a font where the caps are less than x% bigger than small letters, the reduced-size caps will be smaller than the small letters. That's what I see on my browser: the stressed syllables in your preferred variant are smaller than the unstressed syllables, so the stress seems to be reversed (av-RIL L@-veen).

If you change you browser setting for the "small" html tag to fix that font, then the result might not look good with some other font.

The {{sc}} template is different. It chooses the small-cap forms already built in to your font. If your font doesn't have built-in small caps, then the % reduction will have been set at a fixed number by the font designer, just as in how faux-italics and faux-bold works. Most good fonts, however, do have separate small caps, superscript, and subscript, just as they have separate designs for bold and italic. The sc template calls up those characters. Thus if they appear too small to you, it's because you've chosen a font with tiny small caps. The solution is to choose a different font. That's probably a more reliable method than resetting the defs of html tags in your browser prefs. Also, because they were designed to be small caps by a professional typographer, they will be better balanced and weighted than what you get by manually creating faux small caps with the "small" tag. — kwami (talk) 06:22, 12 May 2011 (UTC)

I feel like I'm dragging you through the whole discussion above all over again. Can I post a screenshot of what I see also? I'll be right back. – Kerαunoςcopia^◁_galaxies 06:25, 12 May 2011 (UTC)

Here is what I see: File:Respell_template_example_screenshot.png
Version 1 on both of my browsers shows the caps as being larger than the regular text (and I also use the Modern skin, though Vector skin produced similar results with smaller fonts in general). – Kerαunoςcopia^◁_galaxies 06:31, 12 May 2011 (UTC)

I get the opposite:

File:Respell, html vs template.png

The latter is clearly more legible with my setup. The smaller the font, the greater the difference. If I increase the display size of my browser, they become almost identical, but if I decrease it, your preferred version gets much worse (the stressed syllables become really tiny is comparison to the rest), while the current version maintains its proportions regardless of display size.

IMO, better to take advantage of professional font designers than to mimic them ourselves. — kwami (talk) 09:05, 12 May 2011 (UTC)

Oh my god, thank you so much for reverting the Avril Lavigne article. I had linked to two histories at this discussion as an example, before deciding it was torture to make someone wait for an entire page to load (twice, even!) when I could do the same thing on a sandbox—and then I completely forgot to undo my change. I feel pretty dumb about that. Anyway, this font situation is beyond me. When I increase font size in my preferences, when I change the actual font in the preferences, or if I zoom in the page, or if I limit the zooming in to text-only (Safari has that option, apparently), everything changes equally, and none of the "respelled" text shifts in percentages or at varying sizes. I don't experience what you're talking about. Ah well. I really appreciate your taking the time to respond. Even if I'm in the minority (for some reason) in the end, then I'm still happy knowing that you've made the template better at any rate. So thanks for fixing it all up and for putting up with my haggling! : ) – Kerαunoςcopia^◁_galaxies 10:49, 12 May 2011 (UTC)

Editprotect: use {{smallcaps}} directly

{{editprotect}}

• Change: do not use {{sc}}, but {{smallcaps}} instead.
• Reason: {{sc}} is a construct with options not used here. Possible ACCESS issues (see note below).
• Exact edit: please replace all code in the live {{respell}} with all code from {{respell/sandbox}}.
• Tested: see {{respell/testcases}}. The page has before & after sections (old & new code).
• Note:{{sc}} is to be merged into {{smallcaps}} (see TfD).

-DePiep (talk) 21:30, 22 February 2012 (UTC)

If the result of the TfD was to merge, why doesn't {{sc}} simply redirect to {{smallcaps}}? Angr (talk) 22:32, 22 February 2012 (UTC)

They do different things. This ep is part of the process to simplify the merge.-DePiep (talk) 22:36, 22 February 2012 (UTC)

 Done. Does the documentation need to be updated? Angr (talk) 00:58, 23 February 2012 (UTC)

Thanx. /doc change not needed now, basic effect is equal. Undesired side effects are gone (see also next post). -DePiep (talk) 10:14, 23 February 2012 (UTC)

Is this purely an implementation change, or does it affect how the results display? --Trovatore (talk) 01:42, 23 February 2012 (UTC)

Prime effect is the same: use smallcaps in the stressed parts (=in the alternating syllable groups; as defined by editor input & according to documentation) (good). Secondary: the linked TfD mentions two side effects:

-1. {{sc}} does not use CSS, so user-side settings (skin or scripts) have no effect (bad). While {{smallcaps}} allows manipulating the user side effect (e.g. skip smallcaps visual effect for wp:access).

-2. Still, unchanged, stressed-syllables are changed into lowercase text(!). So copy-paste from the article by a reader still reproduces the changed to lowercase case in text. If this is undesired for WP:ACCESS reasons (I could concur), it should be changed separately ({{lc:}} related). This edit does not change or touch that issue at all.

-Technically, this edit will skip the future, post-merge, {{sc}}redirect. -DePiep (talk) 10:14, 23 February 2012 (UTC)

Edit protect request 26 February 2012

{{edit protect}}

• Edit request: replace all code in the live template with all code from {{respell/sandbox}} (this version)
• Changes:

1.: Force uppercase when stressed, and lowercase when not stressed (old version can show capitals in unstressed syllables: UUM-LAUT)

2.: Use true capitals in stressed syllables. In non-CSS presentation, the capitals remain, and capitals are reproduced when doing copy-paste. {{respell/sandbox|uum|laut}} → uum-laut copy-paste results: UUM-laut

3.: Expanded number of parameters (syllable groups) from 5 to 7

4.: code cleanup: reduce repetitions, do italicising once - now the whole string is italics, even the dashes.

• Tests: See {{respell/testcases}}. The documentation text and table is reproduced for the sandbox. Row are added to show six and seven syllable input (my example texts for these could be better).
• Other pages to be edited: Not necessary (the change does not break any current uses). The documentation description and table could be expanded with options for 6 and 7 syllable groups.

-DePiep (talk) 13:37, 26 February 2012 (UTC)minor edits -DePiep (talk) 13:48, 26 February 2012 (UTC) -DePiep (talk) 09:18, 27 February 2012 (UTC)

 Done Angr (talk) 10:11, 27 February 2012 (UTC)

Undone. The output was screwed up if we used for that four parameters.

It looks like this unsigned remark (from Kwami) is outdated. Anyway such writing is not a way to solve perceived problems. -DePiep (talk) 16:46, 29 February 2012 (UTC)

Yes. Reverted. — kwami (talk) 23:36, 29 February 2012 (UTC)

One check on usage of {{respell}}: "needs IPA"

I have performed one check on incorrect usage of this template. WP:PRON#Other_transcription_systems says that when using {{respell}}, it should be preceded by an {{IPA-xx}} template (e.g. {{IPA-en}}).
I have tagged all pages in mainspace that do use {{respell}}, but not use any {{IPA pattern template. Out of 3085 pages that use {{respell}}, 98 did not use an IPA-language template. I marked them {{need IPA}}, so that is looks like:

• Glendalough (pronounced glen-da-lokh).
  

These 98 pages now show up in category:Wikipedia articles with nonstandard pronunciation. This is the regular category where all "needs IPA" tagged pages are.
How to find these pages? Unfortunately, {{need IPA}} maintenance category does not specify into months (my 98 additions would be in February 2012). They are in one big category, now 275 pages in total. One way to find them is my AWB-edits from today: [1]. One could also use an editors tool like AWB, and pick pages that use {{respell}} and have (parts of) the code I added: {{need IPA|date=February 2012|reason=a template:IPA-xx should preceed template:Respell (WP:PRON)}}. The "reason=" is not reproduced anywhere, but is still added to explain the edit in the page code. It can be that there are multiple instances of this error on one page. (As a side note I can add that nearly a third of the pages were about Irish pronounciation -- in case someone is interested). -DePiep (talk) 18:36, 27 February 2012 (UTC)

Thanks for this. Actually, they should have IPA-en or IPAc-en. Any other IPA template should trigger the warning, since respell can only be used with English, and English should use one of the English IPA templates. A fairly common error is to use respell for other languages, which sometimes means an assimilated English pronunciation without IPA, and sometimes a gobbledygook respelling. — kwami (talk) 23:39, 29 February 2012 (UTC)

Also, I've found a number of cases where we don't have IPA because someone deleted it, saying it's wrong, while leaving the respelling, which they accept, even though the two matched, as at J. M. Coetzee. — kwami (talk) 23:50, 29 February 2012 (UTC)

Nomination for merging of Template:Smallcaps all

Template:Smallcaps all has been nominated for merging with Template:Smallcaps. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Thank you. OwenBlacker (Talk) 19:30, 4 March 2012 (UTC)

Accessibility problems

The edit requested on 26 February 2012 has reintroduced forced capitals, with the use of Template:Smallcaps all, despite the previous edit (replacing Template:Sc with Template:Smallcaps) having corrected this accessibility problem, per MOS:ACCESS, MOS:TEXT and the deletion discussion just last month.

I am liating Template:Smallcaps all, an effective recreation of Template:Sc, with all the accessibility problems that led to its deletion, for deletion. — OwenBlacker (Talk) 19:30, 4 March 2012 (UTC)

Incorrect part: {{smallcaps all}} is different from {{sc}}, at least when sc TfD and merge process were performed (Earlier, {{sc}} was probably different). {{sc}} is merged into {{smallcaps}} after due process: now it is a redirect. btw, I did that merge. -DePiep (talk) 19:55, 4 March 2012 (UTC)

Cleanup uc/lc issues

I propose to add code to the template, so that we can check and cleanup articles using this template having possible uppercase/lowercase issues. In general, when an editor has entered uppercase when the template presents it lowercase (unstressed), there might be a misunderstanding. The same can be said about lowercase entered in stressed (uppercase) syllables.

The proposed code now is in {{respell/sandbox}}, and test examples are in the {{respell/testcases}}. Pages with issues are added to Category:Articles with Respell capitalisation issues.

At the moment we are in "Sandbox mode", to get the demo going. When we want to go live, some code edits are needed before editing the template. It is my intention to have this code and category temporally in the template to reduce future maintenance burden. There are some 3100 transclusions into main article space.

Any suggestions? -DePiep (talk) 23:35, 27 February 2012 (UTC)

Yeah, @me: should we add a "never mind" parameter, so that we can add to the a page {{respell|...|casing=ok}} to drop it from the todo-category? That can make the category really empty, but these parameters will stay there after the cleanup code is removed. -DePiep (talk) 00:00, 28 February 2012 (UTC)

I don't think we should worry about lc, because once caps are no longer necessary in input, people will stop using them. Or at least those should go to a different category. But caps in a wrong syllable does suggest an error, as would caps in a correct syllable when there is lc in another stressed syllable. — kwami (talk) 23:43, 29 February 2012 (UTC)

Yes we should leave out the lc check. Would it be helpful to still do that check temporally?

Step 1, temporally

- we check on uc input and lc input

- lc input issues go to a different category

- we catch the next errors: when multiple lc syllables should be in a group, they are spread over parameters (i.e. an editor used param 3and 4 when an unstressed group was intended).

- There could be very few lc errors while cathing hundred(s). It needs a sweep by looking. Think of it as a backlog.

Step 2, keep the check on UC input permanently

- After some weeks, we remove the check on lc input and its category

- The category with UC errors then stays as a permanent manintenance category (possibly empty, more documentation)

- Unstressed UC input is an error by (Respell and template) definition always

DePiep (talk) 09:17, 1 March 2012 (UTC)

Have put suggestion into the sandbox: differentiate between UC errors and (probably innocent) lowercase input. For now, the "unexpected lc-input" issue is still marked, and with its own separate category: Category:Articles with Respell capitalisation issues (lowercase input). We can thrown this lc-issue check out right now (Kwami proposal), or after a few days/weeks (my proposal). -DePiep (talk) 12:04, 1 March 2012 (UTC)

Yes, of course it would be a good idea to do a check. Many times people simply syllabify without any consideration of stress. Another thing to check for are polysyllabic words in a single cell: that is, only {{{1}}} is used, but it contains hyphens (or sometimes not even hyphens!). We might also want to check for mixed caps within a single cell. This happens often with proper names.

I think we should keep the LC trigger permanent when there are also caps, because this is a fairly reliable indicator of an error. IMO, LC should only be ignored (long-term) when the entire transcription is in LC. — kwami (talk) 19:18, 1 March 2012 (UTC)

We agree. So this is what we'll do.

- I'll prepare the /sandbox to go into live code (no big deal, it only affects maintenance category, and only on ~3000 articles. btw, my bet now for the fun is: ~300 issue pages uc+lc issues will appear).

- Sandbox code for the Live template will be proposed by {{edit protect}}, below.

- This maintenance code is to be permanent, not temporal. Two categories used (Hidden, Wiki-administration, a caring adopting parent cat to be added).

- No parameter needed that does "Page checked and let's not bother about capitals in Respell=yes". Not.

- Other suggested checks: not now. "polysyllabic words in a single cell" - could be checked for, separately. Incidentally, I stumbeld upon this one earlier today (really, and a good example it is): [2]. Interesting, not? But checking for spaces is a differend game. Skip for now. And "mixed caps in single cell" already fails right now, even twice: input=uc? no, input=lc? no. Added to testcases page.

- Since both categories are to be permanent, we will use these names:

• Category:Articles with Respell capitalisation issues (uppercase input)
• Category:Articles with Respell capitalisation issues (lowercase input)

- I myself cannot do the cleanup, because I am not familiar with Respell-practices. Hope you all don't mind when I leave it shortly ;-)

- And a note for Kwami: I like this kind of cooperating. For example, I myself did not think it shpould be permanent. Good process, and productive by result. Appreciated. Have nice edits,

-DePiep (talk) 00:49, 2 March 2012 (UTC)

Code prepared for live template. Tested. See edit request below. -DePiep (talk) 03:28, 2 March 2012 (UTC)

Edit request (1 March, 2012)

• Edit: Please replace all code in {{respell}} (live) with all code from {{respell/sandbox}} (this version).
• Change: No changes in Mainspace. Added is: when expected Uppercase/lowercase does not match input uppercase/lowercase, the page is added to a maintenance Category (to be maintained). Only Mainspaced pages are categorised. The categories are hidden.
• Consensus? Yes. See discussion above. The effect is limited (to Maintenancce categories only).
• Tested: Yes. Sandbox first, final /sandbox code in mainspace (though some stubbord editors were disturbing the test). {{respell/testcases}} contains dozens of lines of test-input. In earlier stages, each line had a concluding text output.
• Effect: I guess some ~300 pages to be listed, out of currently ~3100 transclusions. Maintenance sweep means: check indicvidual pages for intended or mistaken uc or lc usage in this template.
• Other pages to edit: adjust /documentation. And give the two categories a good maintenance environment.
• Check after edit: the editing admin could take a look at the categories, and look at a listed page. Hidden categories can be present. Also, all listed pages (all WLH {{respell}}) should appear normal.

DePiep (talk) 03:28, 2 March 2012 (UTC)

Done. — kwami (talk) 03:59, 2 March 2012 (UTC)

252 and 109 hits. — kwami (talk) 04:43, 2 March 2012 (UTC)

I saw. Nice, innit? 361 = big O(300) for me.

 Done. by Kwami. -DePiep (talk) 04:49, 2 March 2012 (UTC)

I think I'd make the LC cat permanent. I've gone through most of them, and not a single one has been correct.

I used to think people having difficulty with the IPA was an argument for 2ary systems like this one, but a lot of these are absolutely clueless. The one benefit is that when people are unable to transcribe the same pronunciation in IPA and the 2ary, you know one or both are wrong. — kwami (talk) 08:24, 2 March 2012 (UTC)

We can leave them as it is. I cannot help much, I cannot see what would be the correct respelling in most cases. -DePiep (talk) 08:59, 2 March 2012 (UTC)

Countdown: now it´s 8 'lowercase expected' and 199 'uppercase expected'. -DePiep (talk) 23:57, 2 March 2012 (UTC)

The two categories, "uc expected" and "lc expected" have evolved into more permanent. The cat "uc expected" has (now) 180 entries checked for OK (not asurprising situation). -DePiep (talk) 21:28, 17 March 2012 (UTC)

Check for enclosed spaces

Enclosed spaces are possibly not correct (but they can be, e.g. when two words are respelled). Proposal: with current {{respell/sandbox}} code, we can check for enclosed spaces. {{Respell}}-uses that have enclosed spaces are put in the maintenance template:

• Category:Articles with Respell capitalisation issues

Because this is a possibly expensive check (a lot of string manipulation), we should not make it permanent, that could overload future usage. So I propose to install the check for now, check the listed pages, and then remove it. Limits: as for now, the first 25 characters are checked for spaces. If the total input is longer than 25 positions, the page is reported in the same category too.
To any admin familiar with the template (Kwami, Angr): if one trusts this addition, please go ahead and copy-paste /sandbox code in the live template (edit protect request implied). Of course, when one sees strange things (especially in mainspace), it should be reverted. -DePiep (talk) 11:35, 2 March 2012 (UTC)

Will propose edit. -DePiep (talk) 21:39, 17 March 2012 (UTC)

Edit request (17 March 2012)

• Request: Please replace all code from {{respell/sandbox}} into {{respell}} (full replacement).
• Why: The new code tests for spaces in the input, enclosed spaces, to be examined. They could be incorrect. Suspected pages are put in Category:Articles with Respell issues.
• Intention: the listed pages (in the category) can be examined. Since the proposed code is a bit heavy in resources (string working), it should beter be used only for a few weeks. That should do for the check.

-DePiep (talk) 21:39, 17 March 2012 (UTC)

I went to change it, but the only diff is a slight rewording of the categories. — kwami (talk) 22:35, 17 March 2012 (UTC)

Good check, indeed I have removed the code a week ago while waiting. Now it is back, and I tested it on {{respell/testcases}}. If one wants to see intermediate tests (showing a hit in this explicitly, on the test page), just ask. We'll do a pause & proof then. -DePiep (talk) 23:47, 17 March 2012 (UTC)

-So, the edit request is still on. -DePiep (talk) 00:50, 18 March 2012 (UTC)

Done. — kwami (talk) 06:11, 18 March 2012 (UTC)

30 articles showed up. Checked all, and edited some 5 pages. Will ask reversal as planned (see below). -DePiep (talk) 20:48, 19 March 2012 (UTC)

 Done

Edit request (19 March 2012)

Please revert this last edit [3], (request 17 March).

Why? According to plan. This edit (adding a tracking category) is not suitable for permanent use, since it is using resources inefficient. After checking the tracking Category:Articles with Respell issues today (it had 30 articles), some 5 problem pages have been edited. Also, the current temporal code has a bug: the two permanent capitalisation tracking categories have been misnamed, and so now are redlinks (the correct ones are empty). That would be reversed into correct. -DePiep (talk) 20:48, 19 March 2012 (UTC)

Already have switched off subtemplate {{respell/char check}}, one page was capsizing already. This space-checking is off. -DePiep (talk) 01:23, 20 March 2012 (UTC)

Done. — kwami (talk) 11:48, 20 March 2012 (UTC)

 Done

Displaying the schwa

I noticed some PCs with IE can display the schwa [ə] in IPA, but not in these respellings. I assume that's because the IPA templates are designed to ensure correct display. Could that be included in the {{Respell}} template? Lfh (talk) 17:15, 21 December 2009 (UTC)

No? It would be a big help for people using not very up-to-date PCs (e.g. in internet cafes), who currently see a box for the schwa. Lfh (talk) 11:31, 9 February 2010 (UTC)

I've added class="IPA" to the template, which should force the use of IPA-friendly fonts. This should make the schwas legible (at least as often as the schwas in IPA transcriptions are), but at the cost of no longer looking pretty in italics (since most IPA-friendly fonts look like crap in italics). +Angr 12:33, 9 February 2010 (UTC)

Thanks Angr. Let's see how it goes down with people. Lfh (talk) 13:33, 9 February 2010 (UTC)

Actually it does look a bit rubbish on some browsers, doesn't it. Sometimes it makes the schwa look more like ɵ. I like the removal of underlines though, so let's keep that in any case. Hard to know which is better, rubbish schwas or no schwas. Lfh (talk) 14:01, 24 February 2010 (UTC)

Please, use another class and specify its sans-serif fonts if needed. It would also enable those who want to specify fonts for the respelling. I'm specifying an IPA style, but it's very unnecessary for me to see the respelling with. It's like using a Hebrew specific font for Latin. Since {{USdict}} uses the schwa, among other characters, it should encounter the same problem. Someone could make a class for respelling and apply it to both templates, but please, don't add the IPA class to {{USdict}} as well.--Mahmudmasri (talk) 21:05, 28 June 2012 (UTC)

 Done: Ynhockey changed the class from IPA to Unicode and the problem was solved. --Mahmudmasri (talk) 16:18, 27 July 2012 (UTC)

Nice. Minor: now it has underlines (class=IPA prevents that). If there a good reason to rm underlines in Respell, we could do so. -DePiep (talk) 16:56, 27 July 2012 (UTC)

I don't see any underlines. — kwami (talk) 20:27, 27 July 2012 (UTC)

Interesting. As we (we both) know, class=IPA supressed underlines: Main page. Now that class is Unicode, we get this (class=unicode): Main page. I see the underlines appearing. What do you see then? -DePiep (talk) 20:55, 27 July 2012 (UTC)

No underlines in either. — kwami (talk) 05:23, 28 July 2012 (UTC)

Uppercase/lowercase input categorisation flipped

The template currently categorises pages in Category:Articles with Respell capitalisation issues (lowercase input) or Category:Articles with Respell capitalisation issues (uppercase input), but it seems to me that it has these the wrong way around. Quran, for example, uses {{Respell|kor|ahn|'}} (all lowercase input), but has been placed in Category:Articles with Respell capitalisation issues (uppercase input).

Am I missing something, or should this be the other way around?

—me_and 16:08, 1 October 2013 (UTC)

You are right. Or one can read it to mean: "uppercase input required". -DePiep (talk) 20:24, 1 October 2013 (UTC)

Please replace Template:Respell with this revision of Template:Respell/Sandbox – as discussed above, this swaps the error categorisation, since it currently has the upper case and lower case categories the wrong way around. —me_and 12:52, 2 October 2013 (UTC)

 Done — Martin (MSGJ · talk) 12:59, 2 October 2013 (UTC)

Just provide

A functionality to turn the damned autoformat off. For pages where this completely fails like ukiyo-e, we can just use plaintext, but it would be nice to have formatting that DOES just follow where the capitalized syllables are when we write them. — LlywelynII 02:24, 14 August 2014 (UTC)

Probably more easy when the template is done in Lua. But what should it look like for ukiyo-e anyway? -DePiep (talk) 14:33, 14 August 2014 (UTC)

"Cobalt", "perfume" bad examples?

The documentation states:

"The metal cobalt is likewise impractical to transcribe with this system, because people will invariably read KOH-bolt incorrectly, as rhyming with molt and dolt. (This cannot be easily fixed; *KOH-balt and *KOH-bahlt have the wrong vowel.)"

I've got a couple of problems with this. For myself and many others, /ˈkoʊbɒlt/ is an acceptable alternative pronunciation (and is the second one given in the OED), and does rhyme with 'molt' and 'dolt', which is confusing. What's more, assuming the 'correct' reading referred to is /ˈkoʊbɔːlt/, can that not just be spelled KOH-bawlt? Why is this impractical? I'm so confused.

Secondly, a really minor thing is using "perfume" an an example a 2-syllable word with ultimate stress, when it's actually notorious for being a difference between varieties of English, with most Commonwealth speakers opting for PER-fewm. Weird. Maybe it would be better to pick an unambiguous word like "advise", "neglect", "KABLAM", whatever. moogsi^(blah) 12:11, 23 August 2014 (UTC)

Let's replace them with better examples, then. -DePiep (talk) 12:30, 23 August 2014 (UTC)

Sure, I replaced "perfume" with "machine". I have removed "cobalt" which can be unambiguously Respelled as far as I can tell. moogsi^(blah) 16:11, 23 August 2014 (UTC)

Changed the cobolt example to "bolt". It is indeed ambiguous, and no-one has been able to suggest a way to fix it. — kwami (talk) 18:48, 1 September 2015 (UTC)

Template-protected edit request on 1 September 2015

Per WP:VPT#Template:Respell, please merge the sandbox to remove the "Unicode" class, which is not required here. Alakzi (talk) 22:16, 1 September 2015 (UTC)

The linked discussion seems to be ongoing. Suggest wait until consensus is achieved there. — Martin (MSGJ · talk) 10:29, 2 September 2015 (UTC)

Support. The Unicode class allows the user to specify a personal font for esoteric characters not supported by default computer fonts. The trade-off is that most of these fonts (Andika, Gentium Plus etc.) do not support the formats of bold, italic and small caps generated by this template. The result can be rather ugly. The only non-ASCII character supported by this template is the schwa, which already has wide font support (e.g. Calibri, Times New Roman, Tahoma, Cambria, Palatino Linotype, Segoe, Verdana, Warnock, Linux Libertine, to name just a few that I checked). So, little if any need vs. may mess up the display. — kwami (talk) 19:04, 2 September 2015 (UTC)

Discussion has petered out. Change should be from:

<span title="English pronunciation respelling" class="Unicode">

to

<span title="English pronunciation respelling">

(that is, just delete class="Unicode") — kwami (talk) 02:24, 4 September 2015 (UTC)

 Done — Martin (MSGJ · talk) 14:21, 4 September 2015 (UTC)

Much better. Thanks! — kwami (talk) 21:30, 4 September 2015 (UTC)

Link to Wikipedia:Pronunciation respelling key

Wikipedia:Pronunciation respelling key was moved to Help:Pronunciation respelling key. Should the link be changed to go directly to Help:Pronunciation respelling key? Gulumeemee (talk) 04:49, 18 July 2016 (UTC)

Template-protected edit request on 2 August 2016

No one answered my question above, so I am requesting an edit. Wikipedia:Pronunciation respelling key was moved to Help:Pronunciation respelling key. On the first line, please change Wikipedia:Pronunciation respelling key to Help:Pronunciation respelling key so that the template links directly to Help:Pronunciation respelling key.

Gulumeemee (talk) 08:15, 2 August 2016 (UTC)

Done for (;;) (talk) 12:29, 2 August 2016 (UTC)

Small caps may be typographically precious, but they are less helpful than regular caps to the target readers of these transcriptions

Here goes knocking over an anthill. If you look at transcriptions that use this template, the unstressed syllables appear to an untutored eye (which is the target audience of this template) to be bigger than the stressed syllables. This is definitely less intuitive to people who need this template than regular caps would be. No matter how typographically refined or precious small caps may be, anyone being strictly practical about the point of why these transcriptions exist should be able to admit to themselves that regular caps would serve the intended purpose better than small caps do. I am not saying "I hate this template"—this is the only negative point I see about it, and I agree that it is quite helpful for native monolingual English speakers who are "just not that into" topics like spelling and pronunciation transcription. I am simply saying that this one aspect of the template could be improved for better function over form, putting the use case first. Quercus solaris (talk) 01:16, 27 September 2016 (UTC)

I completely agree. It's probably best were the whole respelling reduced in size, with the stressed syllables only bold and capitalized, as illustrated below. If no one responds in a few days, I'll file an {{Edit template-protected}} request. Nardog (talk) 20:10, 13 May 2017 (UTC)

Current template:
Pronunciation (/prəˌnʌn.siˈeɪ.ʃən/ prə-nun-see-ay-shən) lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Proposal:
Pronunciation (/prəˌnʌn.siˈeɪ.ʃən/ prə-NUN-see-AY-shən) lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

Transition to Lua

I've created Module:Respell. It fixes all the problems this template had:

• Each parameter now represents one syllable. You no longer need to put extremely unintuitive {{respell|AL|gə-ridh-əm}} or {{respell|mə|SHEEN|'}}, you can now just put {{respell|AL|gə|ridh|əm}} and {{respell|mə|SHEEN}} and you'll get AL-gə-ridh-əm and mə-SHEEN.
• Support for multiple words. If you put an underscore in a parameter, it will change into a space. So now you can just put {{respell|bə|RAHK|_|hoo|SAYN|_|oh|BAH|mə}}, instead of {{respell|bə|RAHK|'}} {{respell|hoo|SAYN|'}} {{respell|oh|BAH|mə}}, just like with {{IPAc-en}}.
• Now it supports more than 7 syllables in sequence.

See Template:Respell/testcases for examples.

I've corrected all transclusions which were under Category:Articles with Respell issues, so existing uses of the template will remain intact. Nardog (talk) 09:55, 15 May 2017 (UTC)

Erm, in case it wasn't clear enough, please replace the current content of the template with the sandbox. Nardog (talk) 16:51, 17 May 2017 (UTC)

 Done – Quick  Question: does Module talk:Respell/testcases present a problem? (Not an expert at Lua, so not sure I did Module:Respell/testcases entirely correctly.)  Paine Ellsworth  ^put'r there  08:43, 19 May 2017 (UTC)

Thank you very much. I'm no expert either but as far as I know, Module:UnitTests checks if the arguments come out as entered, and the whole point of this template is to transform them, so it is natural it produces errors. Besides, in order to test it you can just call the template as usual and try a bunch of different patterns and it would be obvious in case of an error I suppose. Nardog (talk) 10:22, 19 May 2017 (UTC)

Pleasure! The template testcases page looked good, so I went from that, and I figured that the "self:preprocess_equals" was probably too simple for testing this module. Most likely need the more complex testing that yields a table on the talk page, and that's way beyond my pay grade. Best to you!  Paine Ellsworth  ^put'r there  17:55, 19 May 2017 (UTC)

High-use template

To editor Nardog: of course, there is nothing that says that the {{High-risk}} or {{High-use}} template must be used, but as a template editor, I find it helpful when I see right up front that I'm dealing with one or the other, in this case a high-use template. I've seen many protected templates that also use one or the other of these templates, and I would like to understand why anyone would not want to let people know immediately that this is a sensitive template, so please explain in more detail why you removed the High-use template.  Paine Ellsworth  ^put'r there  19:53, 26 May 2017 (UTC)

@Paine Ellsworth: Well it's just that I felt it would be inconsistent if {{IPAc-en}} and some other protected templates did not have it and this did, and that the fact that it is a sensitive template is rather self-explanatory when there is the padlock at the right top, the edit button only says "View source" for most viewers, and if you click it you'll see why it's protected. It also looks crowded with {{ombox}} and {{lua}}. I certainly wouldn't strongly oppose adding it again, it just felt a little bit superfluous. Nardog (talk) 20:08, 26 May 2017 (UTC)

Okay, as said it's not a mandatory template, just a helpful one.  Paine Ellsworth  ^put'r there  23:30, 26 May 2017 (UTC)

documentation wrong?

Why does the template format everything with bold text in my addition mi-TO-nə-mee to Help:Pronunciation_respelling_key, not just the stressed uppercase syllables as claimed in the documentation and as seen in the same addition here? --Espoo (talk) 18:44, 17 June 2017 (UTC)

That is because the template is linking the respelling to the respelling key page on the key page itself. Add an empty parameter at the end of the template (i.e. |}}) to disable the link. Nardog (talk) 10:45, 18 June 2017 (UTC)

Size fix

W. B. Yeats First the live template, then the sandbox version:
Born	William Butler Yeats (/ˈjeɪts/, yayts) William Butler Yeats (/ˈjeɪts/, yayts)

We need a |size=normal or |small=no or something to this effect Update: problem/solution restated below, to prevent the font-size reduction, with this parameter documented for use only is infoboxes, footnotes, and other places where the font size is already reduced. The problem is that in such a circumstance, the extra font size reduction by this template reduces the output to below the minimum accessible size (I think we've declared that to be 85%; it's at MOS:ACCESS somewhere). See first footnote at William Butler Yeats#Notes as of this permalink for an example. Even with my glasses on I cannot read that without getting my face close to the monitor.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  06:20, 8 December 2017 (UTC)

@SMcCandlish: Instead of adding an option, how about we change <small><i>...</i></small> to <i style="font-size: initial;"><small>...</small></i>? That way the font size will be absolute. Compare:

• CURRENT: Pronounced /ˈjeɪts/, yayts, rhyming with gates.
• SANDBOX: Pronounced /ˈjeɪts/, yayts, rhyming with gates.

Nardog (talk) 07:39, 8 December 2017 (UTC)

That makes it too large, and people will howl about it. We've already had an RfC where just killing off all pronunciation information in the lead was a very close call. On a closer examination (see infobox sample, top right of this thread), the actual problem appears to be that it's just too small in general; the text should be exactly the same size as that produced by {{IPAc-en}}, etc. It will then not be too small in cites and infoboxes and such, and it will also look way more consistent in leads and other running text.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  08:40, 8 December 2017 (UTC)

the text should be exactly the same size as that produced by {{IPAc-en}}, etc. – Then we can just remove <small>...</small>. The reason it is there in the first place is that the template used to use SMALL CAPS for stressed syllables but that made them look smaller than unstressed syllables so we ditched it (see above). Nardog (talk) 08:55, 8 December 2017 (UTC)

Sandbox updated. Nardog (talk) 09:06, 8 December 2017 (UTC)

@SMcCandlish: Thoughts? Nardog (talk) 13:36, 19 December 2017 (UTC)

Just right, size-wise! I hadn't realized the <small> was there for an obsolete reason, and was going to suggest some kind of replacement span with CSS, but am glad none of that is needed to fix the size issue. But, see next thread.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  16:15, 19 December 2017 (UTC)

Over-emphasis fix

Looking at the output on the template's doc page as of this writing, the result (from brief discussion higher up the page) of applying both capitalization and boldfacing for stressed syllables is grossly excessive, and puts us right back in "this is going to trigger people to demand the removal of pronunciation info from leads" territory.

Most especially because MOS:LEAD and MOS:BOLD reserve boldface in the lead for "this is an alternative name for the subject and redirects here".

See MOS:SMALLCAPS: there are multiple small-capping templates, and the one we want is {{sc2}}: SKIT-sə-FREE-nee-ə, -⁠FREN-ee-ə – note that this copy-pastes into ASCII as intended (i.e., without losing the stress distinction): "SKIT-sə-FREE-nee-ə, -FREN-ee-ə".

We could also use some in-template CSS to do something custom, e.g. a slightly taller height for stressed than un-stressed elements; this would also reduce the chain of template calls by not shelling out to {{sc2}}.

1. SKIT-sə-FREE-nee-ə, -⁠FREN-ee-ə = Using {{sc2}}
2. SKIT-sə-FREE-nee-ə, -⁠FREN-ee-ə = Example output with custom CSS (don't look at my wikisource code here; this is just an example-generation kludge)
3. SKIT-sə-FREE-nee-ə, -⁠FREN-ee-ə = The live template's output, but with the bold removed (i.e., still using full-size caps).
4. SKIT-sə-FREE-nee-ə, -⁠FREN-ee-ə = The current live template's output, which is like being machine-gunned in the eyeballs with all that bolding. By combining bold with larger letters we're doubling the emphasis effect pointlessly.
5. skit-sə-free-nee-ə, -fren-ee-ə = An approximation of the former output when that earlier thread was opened. It admittedly was confusing, with smaller caps than regular letters. This didn't look as bad with bolding, because the tiny smallcaps reduce the bolding effect, and the non-reduced size of the lettering of the unstressed parts makes for less distinction between the regular-nonbold and the tiny-bold. But overall, it didn't make much sense.

We should use #1 or – at most – #2.

The problem with the earlier thread, and what was done based on it, is that small caps wasn't the problem; super-small caps was. MOS:ALLCAPS wants us to use small caps here, but not bold.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  16:15, 19 December 2017 (UTC)

@SMcCandlish: Boldface can go, I agree. But I still don't like small caps. I find it more visually intuitive when stressed syllables are distinguished not only by case but also by height. So #3 would be my choice. Nardog (talk) 16:35, 19 December 2017 (UTC)

@Nardog: Well, #2 also does that, but technically complying with MOS:ALLCAPS in not making it quite FULL SCREAMING SIZE. Heh. Can we call #2 the winner? (Of course, others might care, too. There's not urgent hurry, other than for removing the bold.)  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  18:21, 19 December 2017 (UTC)

@SMcCandlish: Sure, I can see that as a middle ground. In actual implementation, though, what font size should we specify? 90%? Nardog (talk) 18:33, 19 December 2017 (UTC)

 Done with 90%. Nardog (talk) 14:53, 28 December 2017 (UTC)

Permitting the use of the Respell template for non-English languages

This template is of course absolutely wonderful and allows one to instantly get a feel for the pronunciation of a word. I would like to suggest that its use be allowed for non-English languages.

Showing IPA for foreign words is good, but they are for most readers of fairly limited use: Only some people actually know IPA, and those who do only know the sounds it describes in their own language. Reading IPA takes a bit of work and one cannot do it at a glance.

It would be great if the Respell template was allowed to be used for foreign words:

• The reader could instantly comprehend how the word is approximately pronounced.
• The reader would not have to open up the IPA guide for every new language they might encounter here and do a slow lookup of sound description. (Finding the description for the Swedish "ɧ", for example, is a tad tedious and no one could be expected to know that particular IPA symbol).

Guides for transcribing IPA into English approximations are readily available on Wikipedia. I do think that allowing the use of Respell in addition to IPA would really augment the experience for the reader, especially for foreign place names.

– Þjarkur (talk) 23:45, 10 December 2018 (UTC)