Talk:International Phonetic Alphabet/Archive 12

Archive 5

←

Archive 10

Archive 11

Archive 12

Archive 13

Archive 14

Someone with AWB access: Please follow the article's own advice re: Angle Brackets!

Until the Oct 22, 2011 revision, this article was generally well readable, as seen in [this revision], but [this edit] used AWB to replace the angle brackets with (U+27E8, U+27E9), in direct contradiction to the article's own comments on the matter. This mass edit should be reversed.

As the article itself states, in the section Brackets and phonemes (4th bullet point Angle brackets): "The true angle brackets ⟨...⟩ (U+27E8, U+27E9) are not supported by many non-mathematical fonts as of 2010. Therefore chevrons ‹...› (U+2039, U+203A) are sometimes used in substitution, as are the less-than and greater-than signs <...> (U+003C, U+003E)." (Emphasis mine.)

I have spent a lot of time messing around with my browser and Unicode support trying to get this page to render correctly. After all that time, I finally discovered the above quote and realized I had been chasing my tail all along. It's not my browser or my Unicode settings that are wrong ... it's the article. Prior to User:Kwamikagami's edit, the only place the (U+27E8) and (U+27E9) codes appeared was in the quote itself, which should be retained to demonstrate that they are, indeed, non-supported codes. I can only assume that Kwamikagami had some foreign language font installed and was not aware of the impact of his/her edit ... but for the rest of us, let's keep this article readable.

The top of this talk page has a RecurringThemes template because of frequent complaints about this article's illegibility. I think the reason these complaints keep coming is because the (U+27E8) and (U+27E9) codes all over this article make it look like the page is unreadable ... when, in fact, the article itself contains its own explanation and solution.

Will somebody with AWB please undo this mess?? Thanks!! 71.192.203.252 (talk) 01:27, 13 November 2013 (UTC)

There used to be a problem, but I tested it out before making the change. We have a chart of angle brackets in 22 common IPA-supporting fonts at Help:IPA#Angle brackets. The brackets display perfectly well when unformatted (system default) as well as when forced to display in all 22 fonts on all four of my browsers – IE, Firefox, Opera, and Chrome – and regardless of whether I'm logged in or logged off, so I don't know where the problem you're having is coming from. — kwami (talk) 01:42, 13 November 2013 (UTC)

There still is a problem, but you don't see it, so does it mean it doesn't exist?? All of the 22 IPA supporting fonts in the page you linked do not display the (U+27E8) and (U+27E9) codes. This is not an IPA problem. I can see IPA perfectly fine, just not the obscure angle brackets. It's not a browser problem. It's not a font problem. The one thing that does occur to me after still further research is it may be an OS problem. What OS are you using?? I'm using Win XP. It turns out these codes are Unicode 3.2, which came out after XP, so perhaps that's where the lack of support lies.

But all this talk of technical issues misses the bigger point: why do you insist on using poorly supported codes for angle brackets when the ASCII character set has perfectly good angle brackets <> that look exactly the same. It is really more important that you tell readers that it's a technical problem and it's your fault, then it is to KISS (keep it simple, silly) and use a widely supported code that looks exactly the same, and only a computer programmer can tell the difference?? Is the answer to say that all Wikipedia readers must user a certain OS, or is Wikipedia for everyone?? 71.192.203.252 (talk) 03:25, 13 November 2013 (UTC)

Don't be an ass. If I test for a problem, and don't see it, that means that I don't know it exists.

As for some of the fonts not displaying these brackets, they all display the same thing, and it's the same thing we have in this article. Word ID's them as U+27e8/9, and the WP software generates them from &#x27e8/9;, so AFAICT they are U+27e8/9. If your OS or browser is generating different characters from the same input, depending on the font, then there's something whacky going on. I'm on Win7, so yes, perhaps XP is the problem.

As for < > looking "exactly the same", they don't: They look sloppy and they cause formatting problems. They're a bit like using asterisks for bullets, or hyphens for dashes: Okay if you're on a typewriter, but to be avoided if you can. — kwami (talk) 03:51, 13 November 2013 (UTC)

Pardon me?? I'm not the one bringing profanity into the discussion. You made the statement, "There used to be a problem," which implies that you believe that it no longer exists. I understand you don't see a problem, and that you are not aware of a problem, but I did not take the time to investigate this, and a write a post, just to amuse myself. There is a problem, but we seem to have a challenge in making you understand that.

Let me be clear: the (U+27E8) and (U+27E9) codes display on Windows XP as square boxes with the hexadecimal digits 27E8 or 27E9 in them. This is Window's way of displaying unsupported Unicode characters. This has nothing to do with Microsoft Word, the font or browser I'm using, or anything else. It appears to do with the fact that the developers of Windows XP did not have a crystal ball and predict that a year later, a new version of Unicode would be released that would contain Angle Brackets that you personally happen to prefer to regular Angle Brackets.

I am no font expert, but in trying to figure this problem out, I did do way more research into Unicode than I would have ever liked to. One thing I found is that virtually no one encodes text directly into Unicode. Generally either UTF-8 or UTF-16 is used to encode text. UTF stands for Unicode Translation Format, and the 8 and 16 refer to 8-bit or 16-bit formats. the Windows NT family uses UTF-16, I believe, while UTF-8 is common in UNIX-based systems. Where the OS comes into it is if the OS does not know how to translate the 8 or 16 bit value into the full Unicode character, the OS is not able to find the character even if it is included in a certain font. I think this may be what's happening here.

The fact that this article states this was still a problem in 2010 tells me that it's likely Windows Vista also failed to support these Unicode characters. Then again, Windows Vista was Microsoft's greatest failure since Windows ME. I, myself, bought a Windows Vista computer, had problems setting things up properly, and the vendor's customer support told me that it was their computer, not mine, so I had to do things their way ... so I sent it back to them. But now that I'm disabled, I'm not able to afford a brand new computer, and my Windows XP works just fine for everything, except for this one web page.

But once again, we are missing the bigger point. Why, exactly, do you insist on using these particular Unicode values for Angle Brackets when there is a simpler solution and, to be honest, has nothing to do with the article's subject, namely the IPA. You state that the ASCII Angle Brackets "look sloppy and they cause formatting problems." I would say that square boxes with hexadecimal values instead of Angle Brackets looks sloppy and is a formatting problem. As for "asterisks for bullets," I can agree. An asterisk is a poor substitute for a filled-in circle, and was only substituted back in the days of ASCII text. As for "hyphens for dashes," what do you mean? An em-dash or an en-dash? An em-dash, absolutely, but an en-dash is not so distinct. Then again, em-dashes are non-migratory.  :-) Seriously, I can agree with your point that those substitutions are "to be avoided if you can." My point is, unless you decide that Wikipedia is only for people with brand-new, Super-de-duper Windows 7 computers, then this is not a substitution that you can avoid.

I also fail to understand what any of this has to do with the subject of the article. Why do we have to argue over hexadecimal Unicode values for Angle Brackets in the first place, when Unicode isn't even part of the IPA? The IPA says nothing about which Angle Brackets are "correct", perhaps because the IPA was created a full century before Unicode was created. The only person, it seems, who insists on using these Angle Brackets rather than any other Angle Brackets is you. I understand, you have a personal preference for these brackets, but with all due respect, you are not the only person who may want to read this page. Your instance on using these Unicode values creates the false impression that something is "wrong" with the user's computer, and that something special must be done to display IPA characters. Actually, IPA characters display perfectly fine without any special configuration on my part ... the only problem is these darn Angle Brackets.

So I ask you, just where on this page do you see anything "sloppy" or a "formatting problem?" If there is nothing wrong on that page, why do we have to break something what wasn't broken?? I'm really confused. I don't understand how I'm asking for too much, here. Can we not simply revert to what was used before, and avoid this problem rather than spend way too much time arguing petty technical points that have nothing to do with the subject? I came here to brush up on the IPA for linguistics work, not to learn about the inner workings of Unicode. Can we KISS and focus on what's really important, here? -- 71.192.203.252 (talk) 00:02, 16 November 2013 (UTC)

Recap for me: this is about U+27E8 ⟨ MATHEMATICAL LEFT ANGLE BRACKET (&lang;, &langle;, &LeftAngleBracket;), U+27E9 ⟩ MATHEMATICAL RIGHT ANGLE BRACKET (&rang;, &rangle;, &RightAngleBracket;) in block Miscellaneous Mathematical Symbols-A}}. IP posts that they do not render correctly; Kwami pointed to the font tests at Help:IPA#Angle_brackets.

Now my point of view. I see these math brackets in a lighter shade of grey. This happens also inline, i.e. in running text as when used here-> ⟩ <- and here-> ⟩ <-. That is not good rendering.

In WP, I have seen this only with these two characters (and some others in the math unicode block they are in, I linked). In the font Help tests: DejaVu Sans is a bit darker (still not black), the top ones are very light, and the lower ones are invisible. My setup is FF v25 atop WinXP. I worked with IPA on this WP for some years, and it started right after the change. Also, I changed to a different PC lately, and the effect is still there. I never installed fonts separately.

So I concur with IP that these brackets do not render correctly. And no user should be required to download fonts or change their setup to read WP. Nd when this can not be solved generally, we should fall back to the nearest working solution. That simply would be < and > brackets. It does not cause misunderstandings anywhere in IPA. -DePiep (talk) 08:31, 16 November 2013 (UTC)

Thank you, DePiep, for a voice of reason in this. Your confirmation has finally moved this discussion into a constructive direction. This is a good example of why issues like this should not be a matter of one man's opinion. It should be a reasoned discussion by multiple participants who work together to achieve a reasonable solution. Thanks again. 71.192.203.252 (talk) 23:32, 16 November 2013 (UTC)

Note that I counter-confirmed (falsified) your XP-theory. My last two XPs recognise both bracket sets. Do you have an idea why those four very old Unicode characters do not appear on your screen? -DePiep (talk) 00:56, 17 November 2013 (UTC)

Break into subtopic: the <math> option

• One other route could be tried: {{math}} formulae rendering: $\langle abc\rangle$ [example 1]. (<math>\langle abc \rangle</math>, see Help:Displaying a formula). This could be applied in templates more easily. -DePiep (talk) 08:31, 16 November 2013 (UTC)

Does that display correctly for you? — kwami (talk) 09:07, 16 November 2013 (UTC)

The math demo shows correctly for me. But: the angles are very high (as in: large fontsize); I cannot see if the line-height is enlarged (that would be bad in running text). I have not looked for reducing size, and when entering legal IPA symbols like ŋm͡ (in IPA template: ŋm͡) it produced a red error. Maybe the <math>-people can help with such details. -DePiep (talk) 09:51, 16 November 2013 (UTC)

How's $\langle$ŋ͡m$\rangle$ [example 2]? That looks practically the same to me as unformatted brackets.

And how about ⟨ŋ͡m⟩ [example 3]? — kwami (talk) 10:28, 16 November 2013 (UTC)

Example 2 looks good here for the topic: letters have regular size & font, brackets are sound but they are high like using all line height - acceptable IMO (more in example 5 below).

off topic

One general point (not related to the math thing): when put in {{IPA}}, the bow across ŋm͡ shifts to the left (over the preceding space and the n; the m is not covered). This happens with and without the math. In example 2, that bow overlaps (crosses) the left, opening bracket. OTOH, in plain text (no template) the bow covers "nm" nicely with me: >ŋ͡m< vs {{IPA}}: >ŋm͡< [example 4]. confusing off-subtopic: see below. -DePiep (talk) 11:22, 16 November 2013 (UTC) Example 3 is same old bad: two very light grey (or invisible) brackets. -DePiep (talk) 11:43, 16 November 2013 (UTC) Example 5: line heights used, with/out math brackets. regular or changed heights? example 5a Some regular text example 5b More example 5c example 5d Some text Abcd. Then $\langle$ŋm͡$\rangle$. Also plain ŋm͡ and {{IPA}}: ŋm͡. Bad bracks: plain⟨ŋm͡⟩, in {IPA}: ⟨ŋm͡⟩ example 5e Some text Abcd. Then $\langle$ŋm͡$\rangle$. Also plain ŋm͡ and {{IPA}}: ŋm͡. Bad bracks: plain⟨ŋm͡⟩, in {IPA}: ⟨ŋm͡⟩ example 5f End of example 5. Cleaned up the example 5 lines. Should show better now (regular text, brackets & yellow bg color). -DePiep (talk) 16:42, 16 November 2013 (UTC) Added with line-height bg color. Cannot find howto color all line height (ie, the vertical space a line occupies, not just some X-height). Maybe later. For me, the lineheights used look the same (=OK). -DePiep (talk) 11:22, 16 November 2013 (UTC) Struck my confusing subtopic/example 4. About how the bow shows above nm: ŋ͡m or ŋm͡ (diff for me here), in IPA template: ŋm͡, is off-topic and can be dependent on my copy-paste. To be solved in another thread. I replaced most occurrences here with a good one. -DePiep (talk) 11:39, 16 November 2013 (UTC) The problem with the tie bar has already been solved. You have a bad IPA font, probably Microsoft. Either that, or someone's added bad fonts to class="IPA". It is not solved, because it shows wrong with me. Does this show a bad bar with you: >ŋm͡< ? It was solved years ago. Yes, of course that's bad: the characters are in the wrong order. — kwami (talk) 15:33, 16 November 2013 (UTC) Is example 5 on another page? — kwami (talk) 12:08, 16 November 2013 (UTC) ??? Example 5 is above, between my 11:43 sign and my word "Added" (six lines numbered 5a - 5f, two have a yellow background). Is fully visible to me. -DePiep (talk) 15:28, 16 November 2013 (UTC) I only see the yellow, even in edit mode. The rest is blank or words like "more". — kwami (talk) 15:36, 16 November 2013 (UTC) I removed some punctuation (using > was not a good idea...). Hope it is visible now. Line height with math graphs is quite to the poiunt I gueass. -DePiep (talk) 16:42, 16 November 2013 (UTC)

How does this compare to ex. 2: ⟨ŋ͡m⟩ [example 6]

— kwami (talk) 12:16, 16 November 2013 (UTC)

Yep, example 6 looks same as example 2. Consider acceptable (I removed the bar issue in exx 2,3,6 by changing char sequence).

Strong suggestion: please change template name asap, stay away from plain "angle" at all costs. e.g. {{math angle}} {{angle brackets}} for U+2728/29. Very confusing & inviting mistakes. -DePiep (talk) 15:28, 16 November 2013 (UTC)

• And one more set of brackets: the U+232x

Jee, I found this. Unicode has another set of brackets. Just see their names.... Worth exploring?

U+2329 〈 LEFT-POINTING ANGLE BRACKET, U+232A 〉 RIGHT-POINTING ANGLE BRACKET. Block Miscellaneous Technical.

Example 101: plain: 〈ŋm͡〉 in {IPA}: 〈ŋm͡〉. (A bit spacy, last one?). They show good & black visible to me! And no {math} needed. -DePiep (talk) 15:14, 16 November 2013 (UTC)

Those are Chinese, which is why the spacing's screwy: They have the same fixed width as all Chinese characters. They aren't the misc. tech block characters because some software somewhere converts them whenever you copy & paste or the page is saved. — kwami (talk) 15:33, 16 November 2013 (UTC)

(edit conflict)They are not marked Chinese in Unicode (nor Han unified nor otherwise), U+2329/2A are definitely in Miscellaneous Technical just by U+number alone. But here is what you want to say: they are canonical equivalent with U+3008/9, which is CJK. And, more to the point: they are deprecated by Unicode. I can't remember "we have been over this", I am just trying to help the topic. -DePiep (talk) 15:50, 16 November 2013 (UTC)

Eg: Here are the misc. tech brackets: 〈 〉 (paste:〈 〉). And here are the Chinese brackets: 〈 〉 (paste:〈 〉). So it looks like if we encode them as &#9001; 〈 &#9002; 〉, then they display correctly, but we can't enter them directly. — kwami (talk) 15:43, 16 November 2013 (UTC)

The old U+2329 〈 LEFT-POINTING ANGLE BRACKET and U+232A 〉 RIGHT-POINTING ANGLE BRACKET of Unicode 1.0.0 would indeed be perfect, but Wikipedia seems to convert them to the East Asian fullwidth punctuation characters U+3008 〈 LEFT ANGLE BRACKET and U+3009 〉 RIGHT ANGLE BRACKET even in the source text after the preview.

The bow/arch should be placed between ŋ and m, thus: 〈ŋ͡m〉, otherwise it displays as a character joining m and 〉 which looks very strange. (My system is by no means typical. Text tagged IPA automatically gets displayed in the font Charis SIL and although I am on Windows my Firefox doesn’t use Uniscribe but HarfBuzz for text rendering.) —LiliCharlie (talk) 16:09, 16 November 2013 (UTC)

This subthread can be closed, no outcome from here. As for the bar: with me it works different (I need it as the third character). Anyway, off-topic. -DePiep (talk) 16:18, 16 November 2013 (UTC)

That's right, I do remember s.t. about them being deprecated. Do we say that somewhere? And why are they deprecated? Do they have poor font support? — kwami (talk) 16:22, 16 November 2013 (UTC)

Deprecated by Unicode: "do not use them any more, althoug Unicode promised never to remove a character from its list". Is mentioned in unicode char list (pdf for block U+3000). Dunno more, and does not seem of relevance to the topic here. Dead end. -DePiep (talk) 16:33, 16 November 2013 (UTC)

So, how does ...⟨...⟩... compare with ...〈...〉...? [example 7, 8] — kwami (talk) 16:22, 16 November 2013 (UTC)

Example 8 shows nice small, as if in regular (surrounding) font height. So even better than example 7. -DePiep (talk) 16:54, 16 November 2013 (UTC)

Those are the deprecated characters. — kwami (talk) 17:01, 16 November 2013 (UTC)

(edit conflict) ;-) replied without seeing you used U+2329/2A. unicode on deprecation: "... be avoided where possible". Thought you didn't like these semi-Chinese characters either. Only research them when the math does not work? I'd accept the bigger math ones for stability (very well supported by Wiki software), above deprecated chars. IMO. (gotta logoff). -DePiep (talk) 17:06, 16 November 2013 (UTC)

It would depend on why they're deprecated. Turns out it's because they rerender as CJK, so it's not a WP problem and there's nothing much we can do to fix it. We can work around it, but will never be able to copy & past them. — kwami (talk) 17:16, 16 November 2013 (UTC)

U+2329 U+232A are deprecated because they are canonically equivalent to and normalize to Fullwidth CJK angle brackets, MediaWiki normalizes strings. Don't use them for what you want to do here, period. This deprecation is reflected in XML Entity Definitions for Characters where &lang; and &rang; used to mean U+2329 and U+232A in XHTML 1.0 and MathML 2.0 but now mean U+27E8 and U+27E9; --Moyogo/ (talk) 08:58, 19 November 2013 (UTC)

Sample fonts

The columns of each set should be identical unless there's a rendering issue.

The second set is the one that's deprecated, and it is also inconsistent in its display, whereas the first pair looks good in all fonts. But we'll need to see how the two look in XP and Vista. It would be nice if we could avoid the template, because with it the page takes significantly longer to load. — kwami (talk) 17:01, 16 November 2013 (UTC)

The second set is deprecated because they recompose into Chinese (CJK) glyphs, and so cannot be copied and pasted: Cf. ...⟨..|..⟩... with ...〈..|..〉.... — kwami (talk) 17:12, 16 November 2013 (UTC)

(edit conflict) Quickreaction. I see: Col 1, 2: bad, light grey or invisible (original problem). Col 3: good, larger brackets. More wrapped lines (due to font, not the brackets?); large brackets seem to stay within lineheight I guess. Col 4, 5: very good, nice with surrounding fontsize. All fonts show brackets correct (black). Quick notes: Maybe ask VPT or so about using deprecated chars & stability (all browsers)? And, has the wide spacing somehow disappeared with these semi-chinese chars? Would be good. Bye for now. -DePiep (talk) 17:17, 16 November 2013 (UTC)

The spacing will come back as soon as s.o. cuts & pastes them. As long as we always use the codes we'll be fine, I think, unless some OS's/browsers can't display them. — kwami (talk) 17:36, 16 November 2013 (UTC)

Summarizing the issue thus far

I appreciate the discussion and ideas that have been offered. For the sake of clarity, I think it's best to recap and summarize things to keep everyone on the same page.

In October 2011, this article was reformatted, replacing ASCII Angle Brackets (example: <X>) with the Unicode characters (U+27E8, U+27E9), which were added in version 3.2. This version of Unicode was published in March 2002, five months after Windows XP, and, understandably, Windows XP is not able to render these characters correctly. It is suspected (though not confirmed) that this problem may also exist with Windows Vista, as it was acknowledged to still be a problem as of 2010. Windows 7 (July, 2009) and newer do not have any display problems with the new Unicode characters. My system, Windows XP Pro SP 3, with Firefox 25.0.1, shows these characters as square boxes with hexadecimal digits, which is Window's way of displaying unsupported characters. Another user, with a similar system, reports seeing the brackets, but "in a lighter shade of grey".

Proposed solutions have included: 1. Telling users the problem's on their end and sending them off to chase an alleged font issue, when it may actually be an OS issue, 2. Replacing the characters with standard ASCII Angle Brackets, 3. Using a math mark-up as a work-around, and 4. Using yet other Unicode characters, with possible other support issues.

For the purpose of discussion, I will use the following examples of each solution:

• Example 1, plain old ASCII: <x> <X>
• Example 2, Unicode 3.2 (U+27E8, U+27E9): ⟨x⟩ ⟨X⟩
• Example 3, Unicode 1.0 chevrons (U+2039, U+203A): ‹x› ‹X› (suggested in article quote)
• Example 4, Unicode 1.0 deprecated (U+2329, U+232A): 〈x〉 〈X〉 (suggested by DePiep. It appears these codes were deprecated back in version 1.1, as part of unifying with ISO 10646, and were never widely implemented.)
• Example 5, Math work-around: $\langle$x$\rangle$ $\langle$X$\rangle$
• Example 6, &lang; and &rang;: ⟨x⟩ ⟨X⟩ (requested by DePiep.)

I think these are all the solutions proposed, other than the Chinese characters, which I think we ruled out on the basis that they're Chinese, and have their own spacing and support issues.

How these examples render on my system (your results may vary):

• Example 1: The height of the angle bracket is slightly taller than the lowercase x, but slightly shorter than the uppercase x. Acceptable.
• Example 2: Hexadecimal digits
• Example 3: Exact same height as the lowercase x, but much shorter than the uppercase X. The top of the bracket comes to just above the mid-point of the uppercase X, and it makes it look like the uppercase X is wearing a pair of gym shorts.
• Example 4: Hexadecimal digits
• Example 5: The height is much larger than the lowercase x, but balanced above and below it. It is also larger than the uppercase X, but the excess is mostly below the baseline, below the uppercase X. The text of Example 6 is noticeably shifted downwards to make space for the abnormally large bracket. (i.e., the space between Example 5 and Example 6 is larger than the space between Example 1 and 2, or 2 and 3, etc. Use your I-bar cursor to point at the descender of the < p > in "Example" to measure the difference.)
• Example 6: Same result and hexadecimal values (U+2329, U+232A) as Example 4.

So, Examples 2, 4 and 6 fail to render at all, Example 3 is too small, Example 5 is too big, and Example 1 is just right. Oddly enough, Example 1, the Goldilocks solution, is (drum roll, please) plain old ASCII. The original objection to these characters was "They look sloppy and they cause formatting problems." Yet, on my system, it is the alternate solutions that look sloppy and have formatting problems. Only Example 1, plain old ASCII, looks "correct", without any apparent sloppiness or formatting problems.

(Sigh) All this talk, just for a pair of Angle Brackets ... which mean "this is not written in IPA." This is what happens when we seek high-tech solutions for low-tech problems. 71.192.203.252 (talk) 23:32, 16 November 2013 (UTC)

Could you describe what you see in the five sample columns, above? Oh and I'll quote something from the IPA page. -DePiep (talk) 00:48, 17 November 2013 (UTC)

All columns except the middle column display hex boxes. The middle column has the too big (Example 5) brackets. The first two columns use (U+27E8, U+27E9) (Example 2) brackets, and the last two columns use (U+2329, U+232A) (Example 4) brackets. Looks like you also quoted the "rendering support" box that sent me on the wild goose chase in the first place. The problem with the page is not, I repeat, not with the actual IPA characters, only with the darn Angle Brackets that are actually not part of the IPA and mean, "this is not written in IPA." The irony does not escape me.  :-) 71.192.203.252 (talk) 01:54, 17 November 2013 (UTC)

Do you see all IPA characters OK? Those added more recent too? btwq, the notice is there to free us from having to support overaged browser setups. Maybe you are in that category. -DePiep (talk) 16:32, 17 November 2013 (UTC)

Please complete example 6 with &lang; and &rang;. -DePiep (talk) 00:56, 17 November 2013 (UTC)

Something strange. Entity &lang; and &rang; were defined in HTML4, December 1997. So way before XP. So why would it not be in your XP version? Do you see any other issues with this list? -DePiep (talk) 01:27, 17 November 2013 (UTC)

Gladly. Done, and comments updated. (They produce same result as Example 4.) As for the reason why, notice they translate to the depreciated characters that were removed from Unicode before XP. The page you linked to, List of XML and HTML character entity references renders fine, except for &lang; and &rang; which the list, itself, defines as (U+2329, U+232A), the depreciated characters. 71.192.203.252 (talk) 01:54, 17 November 2013 (UTC)

-- DePiep, I believe you are also on WinXP. What version, exactly, of XP? I'm on Pro SP3. It occurs to me that if you're on an older XP, SP3 may be "enforcing" the depreciated characters by specifically refusing to render them, while earlier versions simply allowed them to be rendered. It would not be unusual for Microsoft to get heavy-handed in their "fixes." Are these the characters you reported as being rendered in light grey? Perhaps that was intended as a "warning" that they were depreciated characters, and would be discontinued in a future (SP3) update? 71.192.203.252 (talk) 02:15, 17 November 2013 (UTC)

Yes, I have XP, SP2, 3. Dunno about Pro. I won't speculate on windows update actions and what they haven't published. Better find some confirmation first. Core question for me, now, is that you have two pair of Unicode brackets that do not show right. -DePiep (talk) 16:48, 17 November 2013 (UTC)

It might not be an issue of the OS — you’re both on Win XP — but of browser support. MS Internet Explorer developers are very “reluctant” to have users control which fonts are used for display. (Read this on the newly released Internet Explorer 11.) My advice is to test this in several browsers or (better) use a browser in which you can change the layout engine used to display the currently viewed page, like the Avant Browser. —LiliCharlie (talk) 05:28, 17 November 2013 (UTC)

Good thought, though we excluded this at the beginning of the discussion. We're using the latest version of Firefox, 25.0.1. Multiple browsers and fonts were tested, and excluded, leading us to realize the OS may be the underling factor, here. Remember that rendering a page is a browser function, but rendering a font is an OS function. 71.192.203.252 (talk) 05:41, 17 November 2013 (UTC)

Not necessarily so. I am on Windows but have my Firefox render the fonts with HarfBuzz instead of Uniscribe although the latter ships with Windows. (To change this enter URI about:config in the address bar and press return. Use the search field to search for harfbuzz. Right click gfx.font_rendering.harfbuzz.scripts and select modify from the menu that pops up. Change the value from 7 to -1.) —LiliCharlie (talk) 06:01, 17 November 2013 (UTC)

P.S.: Maybe you should compare your versions of Uniscribe (file name USP10.dll). Several Uniscribe versions that shipped with different versions of Win XP are mentioned in the table of the WP article. Even identical Win XP Service Pack numbers shipped with different Uniscribe versions. —LiliCharlie (talk) 06:40, 17 November 2013 (UTC)

It seems then that Example 5 is the optimal solution, except for the fact that the page takes longer to load. As for the objection that the brackets are "too big", they're supposed to be big: The are supposed to be as high as the ascender of a character like b or X, and as low as the desceder of a character like q. So in ⟨|⟩, the tops and bottoms of the symbols should be even, which they are for me. They might not be if they're in different fonts, but that wouldn't be a problem of the the bracket being wrong, but of using different fonts adjacent to each other. — kwami (talk) 08:32, 17 November 2013 (UTC)

Example 5 looks best for me too. I have the experimental MathJax option enabled though (Preferences → Appearance → Math). —LiliCharlie (talk) 08:42, 17 November 2013 (UTC)

Me too. Page load is an issue only when it is ... too long. The complaining IP has two sets of Unicode characters not recognised - doesn't look like a target browser setup for us. -DePiep (talk) 16:41, 17 November 2013 (UTC)

Question: If these are such a problem with XP, why haven't we gotten complaints from other high-traffic articles where they're used, like Greek alphabet? — kwami (talk) 09:59, 17 November 2013 (UTC)

And I add: if it is about old versions of XP/browser, why do the more recent IPA additions to Unicode (like: from SIL proposals) do not cause complaints by IP? Some sort of selected updates only? -DePiep (talk) 16:32, 17 November 2013 (UTC)

I doubt it's that XP is too old. Probably just a bug that they were incapable of fixing, or like the bugs in their IPA fonts that they never fixed either. — kwami (talk) 17:10, 17 November 2013 (UTC)

We just had s.o. change the template back to plain Math-A brackets. It does seem to be very rare that people can't read these: We have them in the Arabic, Russian, Italian, Spanish, Mandarin, Egyptian, Latin, etc etc. language pages, which get a lot of traffic, and they don't seem to be a problem. Could it just be an issue if you have XP and never got it updated? — kwami (talk) 14:00, 17 November 2013 (UTC)

I reverted, that was the point of the template. It's <math> again. -DePiep (talk) 16:38, 17 November 2013 (UTC)

Has anyone asked <math> people if the high brackets can be reduced to half, legally? -DePiep (talk) 17:25, 17 November 2013 (UTC)

Changing the new template should not be done while talk is going on. If things are not fleshed out enough here, the template should not be put on mainspace in the first place. -DePiep (talk) 17:29, 17 November 2013 (UTC)

Good comments, but let's re-summarize and bring the discussion back into focus

Wow, we've got multiple people jumping in on each other, and I'm having a hard time following what's going on now. So, I hope you can excuse me for trying to re-summarize things, again, and get everyone on the same page. Personally, I came here to brush up on the differences between French and English vowels, and how they relate to other Romance (e.g. Spanish, Italian) and Germanic (Dutch, German) languages. Instead, I've gotten a technical and history lesson in Unicode, and an education about how Microsoft has completely eliminated the distinction between an application and an OS.

I understand that my issue may help you understand some technical problems you've never quite fully worked out, and that you may not have had a user who was able to describe and cooperate with you to my extent, so you're a bit eager to try out all sorts of new theories, but let's try to keep the discussion organized and focused. We seem to keep asking the same questions again and again. Also, I think the questions you're asking me apply the other way around, too. Please describe what you're using and seeing, too. I can't provide useful information if I don't know what you're seeing or supposed to be seeing. Make sense??

I realize some people may not know how/where to find all the info that's being asked for, so I'll summarize my system, with directions on how I found the answers. If everyone else can do the same, we can start figuring out if this is really an OS problem, font problem, browser problem, etc., etc. If you have multiple computers, please identify each of them separately so we don't get confused between them.

My (plain old Wikipedia reader, or "IP" for short) system:

• OS: Windows XP Professional Service Pack 3 (right-click on My Computer, Properties)
• Browser: Firefox 25.0.1 (Help, About)
• Uniscribe: 1.420.2600.5512 (C:\WINDOWS\system32\usp10.dll, hover over the filename, or right-click, Properties, click on Version tab.)
• Fonts: no "special" fonts installed
• Font software: no "special" font software, just what the OS and browser installed by default.
• "Special" settings: I have not gone into secret, magical places and changed any registry keys or uttered any magic phrases. I'm using a plain, vanilla system such as a typical user can be expected to have.

It turns out Uniscribe was first released as part of IE 5.0, and was part of Microsoft's back-support for Unicode for non-Unicode OS's (Win 95 family), and later became part of NT 5.0 (a/k/a/ Win 2000). As of Windows 7 (really NT 6.1), it's been replaced with DirectWrite (though Uniscribe remains available for backwards compatibility), so this may be where we're seeing the XP/Vista vs. Win 7+ differences. Or not. (One must remember: you cannot prove a theory if you do not first throw a theory out to be proven ... or dis-proven.)

The Uniscribe story does shed some light on how web browsers, in particular, began to ignore the OS font support and provide their own font rendering due to the prevalence of UTF-8 encoding on the Internet, and the need to display this text on non-Unicode OS's (Win 3.x, 95/98/ME, and possibly older versions of Mac). So the idea that Firefox still contains its own font engine makes sense in that light.

Perhaps this is why the actual IPA characters render fine: they're being rendered via Firefox, but that does not explain why certain Angle Brackets are being rendered inconsistently with the same browser. Then again, text is almost never encoded in raw Unicode, but rather in a UTF encoding. Where, exactly, does the UTF translation occur? Given the history lesson, it's likely that UTF translation (and font rendering, for that matter) may occur both in the browser and the OS. What if we have a character that the browser doesn't know how to handle? What would it do? I would guess it would pass it to the OS to have it give it a shot. Then, if the OS doesn't know how to handle it, the OS would render the hex digits. This may be why we're all right (and all wrong) in our suggestions. The browser is rending most (I repeat, most) of the characters, which is why IPA renders fine, but the characters that the browser doesn't know (perhaps those annoying Angle Brackets?), it passes to the OS, where we see inconsistent results because we're on different OS versions.

Given that I use the latest version of Firefox, downloaded just a few days ago, and other users reporting different behaviors are using the same browser version, I do think we can eliminate the browser as our primary focus. Or not.  :-) But I think we'll get better results if we turn our focus to the proposed solutions and how they work (or not).

The first four solutions involve using different Unicode characters and default rendering:

• Example 1, plain old ASCII: <x> <X>
• Example 2, Unicode 3.2 (U+27E8, U+27E9): ⟨x⟩ ⟨X⟩
• Example 3, Unicode 1.0 chevrons single guillemets (U+2039, U+203A): ‹x› ‹X› (suggested in article quote)
• Example 4, Unicode 1.0 deprecated (U+2329, U+232A): 〈x〉 〈X〉 (suggested by DePiep. It appears these codes were deprecated back in version 1.1, as part of unifying with ISO 10646, and were never widely implemented.)
• Example 4a, Unicode 1.0 CJK (U+3008, U+3009): 〈x〉 〈X〉

These solutions generate straight UTF-x encoded text, rendered by the browser and/or OS.

Some additional comments on these options, from further research. Example 3, it turns out, are not chevrons, as suggested by Wikipedia sources, but rather, they are a form of guillemet, a punctuation mark. French uses a double guillemet as quotation marks: « Bon jour! » These characters are a single guillemet. As for Example 4, the story, it turns out is much more complicated than some Wikipedia sources would make it seem. Version 1.0 introduced both the Misc. Technical (Example 4) angle brackets, and the CJK (Chinese, Japanese and Korean) Symbols & Punctuation (Example 4a) brackets. However, as of 1.1.5 (July 1995), there was a notation added to the Misc. Technical brackets that they were essentially equivalent to the CJK brackets. The problem with this is that CJK characters are spaced differently than Latin characters, and the Misc. Technical brackets could legally be rendered with wide extra spacing that works fine with CJK, but looks terrible in Latin. This was fixed in Unicode 3.2 by creating the Misc. Math Symbols-A (Example 2) brackets, and by changing the status of the Misc. Technical (Example 4) brackets to "depreciated." What this all means is that the only thing we can count on with Example 4 brackets is that we cannot count on them. They are forever tied to (and tainted by) the Example 4a CJK brackets. Possible valid side effects of all this could include: Example 4 brackets might not be rendered if CJK fonts are not installed, or if rendered, may be rendered in CJK spacing, or other undefined results. I believe this was discussed earlier, but the meaning of what was said went way over my head, at the time.

A fifth solution, the one most people are centering on, right now, is a work-around:

• Example 5, Math work-around: $\langle$x$\rangle$ $\langle$X$\rangle$

This solution generates the following HTML:

<img class="tex" alt="\langle" src="//upload.wikimedia.org/math/d/3/d/d3d5d8dda90ca3cd1168953029ac8dd2.png" />
<span title="Representation in the International Phonetic Alphabet (IPA)" class="IPA">x</span>
<img class="tex" alt="\rangle" src="//upload.wikimedia.org/math/7/4/e/74e81401cb89957d325c6da172eae120.png" />

<img class="tex" alt="\langle" src="//upload.wikimedia.org/math/d/3/d/d3d5d8dda90ca3cd1168953029ac8dd2.png" />
<span title="Representation in the International Phonetic Alphabet (IPA)" class="IPA">X</span>
<img class="tex" alt="\rangle" src="//upload.wikimedia.org/math/7/4/e/74e81401cb89957d325c6da172eae120.png" />

So what's happening behind the scenes, here, is we're using a pair of .PNG graphics to replace the Angle Brackets. This is why we're increasing the download / render time for the page, and also why we're throwing the line spacing off whack. (The .PNG are at a fixed height, with no relation to the font height being used to render the rest of the text.)

A sixth solution uses HTML mark-up, but really is just a substitute for Example 4:

• Example 6, &lang; and &rang;: ⟨x⟩ ⟨X⟩ (requested by DePiep.)

As for the Unicode solutions, it must be noted that Example 4, (U+2329, U+232A), was part of Unicode for only two years, 1991-1993, and were never part of ISO 10646. Support for those characters probably happens when font designers fail to notice the footnote that these codes are depreciated, and accidentally include them. I think that by definition, we must expect support for these codes to be inconsistent, and the standard clearly advises us to avoid using them. As for Example 2, (U+27E8, U+27E9), these codes were added five months after Windows XP shipped, so we cannot fault Microsoft for failing to be psychic.

So with that being said, we're left with Examples 1, 3, and 5:

• Example 1, plain old ASCII: <x> <X>
• Example 3, Unicode 1.0 chevrons single guillemets (U+2039, U+203A): ‹x› ‹X›
• Example 5, Math work-around: $\langle$x$\rangle$ $\langle$X$\rangle$

Typographically, the way these brackets render on my screen (your mileage may vary), Example 3 is too small, Example 5 is too big, and Example 1 is just right. Kwami, on the other hand, states that "they're supposed to be big." Honestly, that comment had me ROFLMAO, because I believe he was the one stating that his objection to Example 1 was, "They look sloppy and they cause formatting problems," and that he invoked the Asterisk versus Bullets argument. What I failed to understand was that he was arguing for the asterisk instead of the bullet! At least, that's what it appears to me. What I believe may be going on is that the examples look very different on his screen, but we haven't heard him describe what he's seeing, exactly, so we're only guessing here, and probably guessing incorrectly. Are the brackets so big that they throw the line spacing off, and that there are noticeably larger gaps between lines with Angle Brackets than between lines without Angle Brackets? Probably not. But that's what I see.

This is a big problem in this conversation: we're all assuming that everyone is seeing what they're seeing, and they're not. That is the problem. Which is why I'm asking y'all to answer the same questions you've asked me ... so we can all understand what each other is seeing and to work together towards the same goal. I think we have different ideas of what the goal is.

So to that end, I think it's imperative we agree on what a properly typeset page with the "proper" Angle Brackets should look like. Can anyone produce a link to a raster graphic image of a correctly typeset page ... one that we can all see correctly, and all agree is a good example of proper typesetting, so we can all have a common reference to work with? I think this, alone, will help clarify some of the misunderstandings we all seem to be having, and get us to understand each other's points far more quickly and effectively.

Also, as to the question why haven't you gotten more complaints, if this is such a big problem? I think you have gotten complaints, but your standard answer has been to blame the user, and most users, IMHO, would say, "oh, well", give up, and not bother to figure the problem out. In fact, that's what I nearly did, until I finally realized that I was seeing IPA characters, and the ton of hex boxes were showing the same pair of codes, over and over, again. That's when I finally realized it's not the IPA that's the problem, it's what I now know to be a pair of bleeping Angle Brackets that have nothing to do with the IPA. 99.9% of your everyday users aren't going to troubleshoot a problem like this the way I did. Most of them would just Google search for another website, which I nearly did!

-- plain old Wikipedia reader, or "IP" for short 71.192.203.252 (talk) 01:41, 18 November 2013 (UTC)

You can test both Uniscribe and font support with BabelPad. Download the Program and save it to some folder. Then copy the Uniscribe file you’d like to test (file name USP10.dll) to the same folder. If you now run BabelPad you should see which Uniscribe version it uses via the Help menu. Now input or copy some character(s) into the editor and highlight them, no matter what they look like. Via the menu, select Tools → Font Coverage.... Now there should be a bullet in front of all characters in this text and the highlighted text should be in the input area below this. Just press Calculate Font Coverage and a list of fonts should appear in the Matching Fonts area. Selecting one of the fonts in the list will show you what the characters look like when rendered with that font. HTH. —LiliCharlie (talk) 03:47, 18 November 2013 (UTC)

I appreciate your mentioning this tool, but I'm not sure how it advances the discussion. I may be missing your point, entirely. Windows has a similar tool, Character Map, (found under Accessories, System Tools) that doesn't require downloading anything. What may be helpful is if you stop, and answer me these questions three, 'ere the other side, he see: What are your versions? What do you see to each example? What is your favorite Angle Bracket?? :-) -- plain old Wikipedia reader, or "IP" for short 71.192.203.252 (talk) 00:41, 19 November 2013 (UTC)

For what it’s worth,

I used “Example 3, Unicode 1.0 chevrons single guillemets (U+2039, U+203A): ‹x› ‹X›” when I set up the fr:Modèle:Graphie on the French Wikipedia. After looking more into it there are French books that actually do that, that use the single guillemets for this usage. --Moyogo/ (talk) 09:06, 19 November 2013 (UTC)

This is the second time that there is true progress into a solution, and you restart & rewrite the whole discussion. Since this does not reflect the various arguments made, on how to improve the situation, I feel not invited to read into or respond to this section. Please just close it, IP, and joint the other threads when possible. -DePiep (talk) 11:12, 19 November 2013 (UTC)

Complication with math coding

The math coding currently in {{angle bracket}} does resize as needed. However, it screws up the TOC when used in section headings. See §4 at yogh. — kwami (talk) 04:40, 19 November 2013 (UTC)

Too bad! As mentioned above math mark-up is the solution that looks best for me. But such a screwed-up display in the TOCs seems to make it unusable I’m afraid. Let me put it this way: a minor improvement for the benefit of a couple of readers on older systems should not lead to a major confusion of all. — I keep wondering what it is that makes some Win XP users see garbage, but not others. —LiliCharlie (talk) 15:20, 19 November 2013 (UTC)

re: There is some more talk on this at Template talk:angle bracket. I do have issues in this (text showing less good), but I am not requiring that WP should be adjusted to my exotic situation. I do want a stable and qualitative acceptable solution for WP, btw which is not wholly the same as what the OP IP aimed at (< >). I was just exploring the other options we have in here. Found two sets - nice, even if not used in the end. Learned some <math>. too. -DePiep (talk) 15:29, 19 November 2013 (UTC)

Commenters at the Village Pump think it's not IP's OS, since XP supports unicode characters that came out after it did, but rather the combination of browser and fonts. There seem to be very few people who have this problem. It looks like the best solution is to use the proper characters, as we had been doing, but perhaps formatting would help. IP, do any of these look better than the others?

1. ⟨ ⟩
2. ⟨ ⟩
3. ⟨ ⟩
4. ⟨ ⟩

We could also span them for preferred fonts. Do any of the fonts in the left two columns of the large table above look better than the others? — kwami (talk) 12:13, 20 November 2013 (UTC)

Added #4, that made the template OK for me (visible, black angles). rv me if undesired edit. -DePiep (talk) 12:22, 20 November 2013 (UTC)

I have almost all of these fonts installed on my system, and most look fine. The only ones I find inappropriate are Linux Libertine (tapering “arms”), Quivira (same reason), Everson Mono (too wide) and Code2000 (too high). —LiliCharlie (talk) 12:45, 20 November 2013 (UTC)

Answering kwami: above, fonts DejavuSans and Linux Libertine are better (darker grey, acceptable) in col 1 and 2. CEnter col ok OK all over of course. -DePiep (talk) 13:00, 20 November 2013 (UTC)

I'm not a linguist.

It is very frustrating to read articles about languages, encounter IPA, and then still have no idea how anything is pronounced because this page doesn't contain a pronunciation guide. I'm happy that so many readers seem to know what a "voiced alveolar fricative" is, but it would be more helpful just to include English pronunciation with the main table.--68.61.5.58 (talk) 12:28, 4 April 2014 (UTC)

This is an article about the IPA (its history and use etc.), not a guide to how to use IPA pronunciation guides. For that, all you have to do is click on the pronunciation guides in the articles, which should take you to a page with precisely what you're looking for. For example, clicking on the second IPA guide on the Jacques Chirac article takes you to Wikipedia:IPA_for_French. Clicking on a letter of the first guide (which aims to give the standard English pronunciation) takes you to Help:IPA_for_English#Key. Garik (talk) 13:28, 4 April 2014 (UTC) edited by Garik (talk) 13:33, 4 April 2014 (UTC)

You might also have noticed the following at the top of this article: For usage of IPA in Wikipedia, see Help:IPA or Help:IPA/Introduction. Garik (talk) 13:33, 4 April 2014 (UTC)

New IPA – SIL keyboard

It doesn't look like there's any kind of guide or Help page or I don't know what for the new Universal Language Selector yet, but you can find all the key mappings for the IPA keyboard in this little JS file. — Lfdder (talk) 11:13, 2 July 2013 (UTC)

Error 404 – File not found Tohuvabohuo (talk) 15:43, 11 April 2014 (UTC)

https://github.com/wikimedia/mediawiki-extensions-UniversalLanguageSelector/tree/2014.03/lib/jquery.ime/rules/fonipa — lfdder 16:20, 11 April 2014 (UTC)

Letterforms ... WTF?

I quote from the article:

"The letters chosen for the IPA are meant to harmonize with the Latin alphabet.[note 5] For this reason, most letters are either Latin or Greek, or modifications thereof. Some letters are neither: for example, the letter denoting the glottal stop, ???, has the form of a dotless question mark, and derives originally from an apostrophe. A few letters, such as that of the voiced pharyngeal fricative, ???, were inspired by other writing systems (in this case, the Arabic letter ?? ‘ain)."

• If the letter denoting the "glottal stop" is three question marks -- ??? -- then why does it go on to say it "has the form of a dotless question mark"?
• Is a "glottal stop" the same thing as a "voiced pharyngeal fricative", since they are both denoted by the same triple-quesstion mark?
• Is the "Arabic letter" refered to "??", or is it "`ain" or is it "??`ain" ? This is not clear from the description.

The section goes on:

"Despite its preference for harmonizing with the Latin script, the International Phonetic Association has occasionally admitted other letters. For example, before 1989, the IPA letters for click consonants were ???, ???, ???, and ???, all of which were derived either from existing IPA letters, or from Latin and Greek letters. "

• "Click consonants" seems unnecessarily vague: which consonants are these? C,K,Q,X ? C,D,F,G? W,X,Y,Z? Why not just list them and remove the ambiguity?
• If all of these "click consonants" are denoted by the same symbol, why repeat it four times? Wouldn't it make more sense to actually list the consonants and then say they're all denoted by "???" ?
• Is the symbol for all of these consonants really identical with that of the "glottal stop" and "voiced pharyngeal fricative"? If so, how does one tell them apart?
• In both cases it is unclear whether the symbol is " ??? " or "???, "

I would suggest using quotation marks to clarify which characters belong to the symbol, and which are punctuation for the article.

And still further on:

"However, except for ???, none of these letters were widely used among Khoisanists or Bantuists, and as a result they were replaced by the more widespread symbols ???, ???, ???, ???, and ??? at the IPA Kiel Convention in 1989."

• Say what? The "Khoisanists or Bantuists" didn't use the triple-question mark "letter", so they replaced it with ... the same triple-question mark?

The article is full of pseudo "explanations" like these which make absolutely NO SENSE to a layman. The article seems written for a academic linguist inpossession of the mysterious knowledge of how to tell one arbitrary group of question marks from another apparently identical group of question marks (by context?). At any rate, I think the article requires a major rewrite.

And while you're at it, the "illustration" of the full IPA displays as a black box with a few featurless grey blocks in the upper third of the box. Perhaps an actual visible chart of the alphabet would be more useful? — Preceding unsigned comment added by 67.206.162.36 (talk • contribs)

There should be no occurrences of '???' on the page, so I think you are having some problem with viewing the page. Because IPA uses bleeding edge bits of Unicode/HTML etc, this page is susceptible to rendering problems. Please check if you can read the page properly by fiddling around with encoding options etc in your browser (or try a different browser). If the problem will not go away I suggest you ask again with details of your setup. Fundamentally the article is supposed to be readable! Imaginatorium (talk) 07:13, 23 July 2014 (UTC)

Can somebody add the best teaching/learning software games for the IPA in the related links section?

Hi
Is there something like that out there?
I have a 3D Animation of the skull in mind
where you see the tongue and all the other movements
connected with making a voice or noises like the vocal cords,
the palate and lips for studying it and
more playful games like a karaoke engine
that shows words and sentences and a translucent bar
moves over the word and IPA signs to show what the voice is telling.
Does anybody know where I can find that?
I only found this terrible thing:
http://www.purposegames.com/game/ipa-consonants-quiz
If you know something like that please post a link
on the wiki page and send me an email.
My email is my account name at Google mail.
--Jangirke (talk) 03:25, 10 September 2014 (UTC)

Whistling

How is whistling represented in the IPA? I know for a fact that several African and Native American languages have whistling in their languages, so how would you represent this? Would it perhaps be represented as IPA: [s͍͎ ]?

@Cameron Brimhall: Please sign your talk page entries, either with ~~~~ or by using the pencil "signature" icon, third from the left in the talk page formatting bar, just after B and I.

1. It isn't.
2. No, they don't. There are so-called "whistling languages" that are used to communicate across distances, but these are not languages in the usual sense. Can you give references for what you "know for a fact"? --Thnidu (talk) 04:17, 7 January 2015 (UTC)

Diacritics and allophones

Concerning slots on the chart that have no basic symbol, the article now says:

"Diacritics can supply much of the remainder, which would indeed be appropriate if the sounds were allophones."

I'm somewhat concerned with this, because to my knowledge there is no necessary association between diacritic transcription and allophonic status in IPA. For example, you would use the palatalization diacritic to transcribe the palatalized consonant phonemes of Russian, and you would use the separate beta/eth/gamma symbols to transcribe the fricative allophones of Spanish /bdg/. Unless someone points out something I'm missing here, I propose to remove the part of the sentence above that follows the comma. BruceHayesUCLA (talk) 02:53, 29 October 2014 (UTC)

@BruceHayesUCLA: I fully agree, and I'm about to do it. Thanks for pointing it out. To discuss this with me, please {{Ping}} me. Thnidu (talk) 04:20, 7 January 2015 (UTC)

Font links gone

The box at the top of this talk page says (second bullet in the first pane)

• I can read the IPA, but not on Wikipedia. It either doesn't display correctly, or appears in an ugly or illegible font.

See the bottom of the article for links to several fonts that support the IPA if you don't have one installed.

There are no links to fonts in the article. Without doing a search, I suspect that someone took them out because s/he considered them advertising.

I'm posting a link to this Talk entry to the Talk pages of the three projects mentioned in the bottom of the box. To discuss this with me, please {{Ping}} me. Thnidu (talk) 04:37, 7 January 2015 (UTC)

@Thnidu: I did a little rummaging in the History page, and found this edit. It seems the note was moved to Help:Special characters § IPA symbols; that section should be linked in the note above. — Eru·tuon 05:11, 7 January 2015 (UTC)

And now it is. — Eru·tuon 05:17, 7 January 2015 (UTC)

@Erutuon: thanks! --Thnidu (talk) 07:02, 7 January 2015 (UTC)

Angle brackets

What's with the boxes? I see ⟨b⟩ for example. Is this some standard or a fonts issue? meant to represent [] or entirely different symbol?--146.90.44.114 (talk) 18:00, 4 February 2015 (UTC)

⟨ and ⟩ are angle brackets. Anything between angle brackets is an example of orthography; the angle brackets mean something like "stuff here is an example of letters or writing". Anything in square brackets is an example of phonemes, and anything in slashes is an example of phonetics, meaning the actual pronunciation of phonemes. An example of usage:

The letter ⟨t⟩ represents the phoneme [t] in English, and the phoneme /t/ has the unaspirated allophone [t] in ⟨stop⟩, aspirated [tʰ] in ⟨top⟩, and sometimes glottalized [tˀ] in ⟨pot⟩.

— Eru·tuon 23:03, 4 February 2015 (UTC)

Android notes:

• U+27E8 (⟨) and U+27E9 (⟩) (mathematical left/right angle bracket) do not appear in Android in the Wikipedia app, at least not with supplied fonts; neither do they appear in Google Chrome (Android)

• U+2329 (〈) and U+232A (〉) (left/right-pointing angle bracket) which are deprecated, appear in the Wikipedia app, but not in Google Chrome (Android). This appears to be how the lang and rang HTML entities are being realized.

• Only U+3008 (〈) and U+3009 (〉) (left/right angle bracket in Chinese punctuation) are working in both the app and in Chrome.

just fyi. – RVJ (talk) 06:20, 3 March 2015 (UTC)

Audio Recordings

I appreciate the audio files. However I feel that many of them, especially the vowels, are poor representations. To this end I have recorded some sample vowels and uploaded; please check them out and let me know if you would like me to do more. If people like them, I will upload a full vocalic repertoire and we can replace the current ones. I would be into uploading some consonants as well. Any suggestions / critique welcome, I am almost entirely self-taught so it is possible I have some of the sound values slightly off. Let me know if you think my sounds are accurate or give suggestions for how they could be better! See here. More to come soon. Shouai (talk) 01:05, 7 February 2015 (UTC)

Cheers Shouai, I very much appreciate your effort. — This makes me wonder if Daniel Jones’s nearly authoritative original recordings of the 8 primary and 10 secondary cardinal vowels are still copyright protected after so many years. In case they are in the public domain by now I strongly recommend considering using those.

As to recordings you’ve uploaded: To my ear [ᴜ] lacks sufficient lip-rounding, and [y] as well as [a] are not entirely front. (In everyday life, i.e. when applied to common accents of common languages, the symbols [y] and [a] often, or even usually, have a value close to yours; however this is not their cardinal value. Note however that the Handbook of the International Phonetic Association doesn’t seem to refer to cardinal vowels at all, so my relying on them as reference points within a neatly delimited continuum may be somewhat out-dated. Yet I believe that this “London tradition” is the most widespread among trained phoneticians, and one of the best defined, to boot.) LiliCharlie (talk) 19:00, 7 February 2015 (UTC)

Thanks LiliCharlie. I felt inclined to contribute because I have been thinking for a while about how the IPA recordings are not really up to par (and I think I have spotted comments in the talk pages which suggest I am not the only one who thinks so). While I do not doubt the accuracy of Mr. Jones' recordings for a second (and it may well be that these are the best recordings to use), I would like to suggest that we can do even better, at least in terms of recording quality. I am sure there are many people more qualified than I to do this work; on the other hand I am happy to do it, assuming I can provide suitable recordings.

I am 100% in agreement that the IPA recordings ought to reflect the pure, standard cardinal value of the letters. Being a self-taught linguist, my idea of these cardinal values may be slightly skewed. If you don't mind, have a listen to this recording of the frontal vowels and let me know if you think it is more accurate.Shouai (talk) 23:43, 7 February 2015 (UTC)

[ɐ]

[ɵ]

Hey, I applaud any effort to whip Wikipedia's coverage of phonetics into shape. However, as I said in Talk:Open-mid back unrounded vowel § Audio, your recording of [ʌ] actually has the vowel [ɐ]. Thus, your recordings of [ʌ] and [ɐ] are almost identical.

I think the reason for the objections to the recordings of [ʌ ʊ] is that the IPA cardinal values of these symbols don't actually occur in standard American English. In my dialect, at least, the vowels represented with [ʌ ʊ] in Help:IPA for English are lowered and centralized to [ɐ ɵ]. Thus, my pronunciation of the vowels in but and good is almost identical to the vowels in the recordings to the right. Let me know if this is also true of your pronunciation, Shouai. (I'm assuming you speak American English; my apologies if this is wrong. However, the mismatch may be true of other English dialects as well.) If so, then perhaps the existing recordings of [ʌ ʊ] are actually accurate. — Eru·tuon 05:56, 8 February 2015 (UTC)

I would like to get involved in this discussion about recordings of sounds relevant to the IPA - it's something I have views on as a professional phonetician. I'm in favour of having sound illustrations wherever possible, so I'm glad you are already active in this, but I am anxious that they should be in line with the norms of practical phonetic training, for obvious reasons. I can't actually see any audio "click and listen" features in the article for which this is the Talk page. The nearest thing seems to be links from symbols on a vowel chart to specific pages for specific vowels. Is it the recordings used on those pages that you are talking about? Incidentally, I feel that there should be a substantial section on practical phonetic training in the article on Phonetics - or maybe a separate page? I hope I can contribute something on this soon. RoachPeter (talk) 14:28, 8 February 2015 (UTC)

Yes, a separate en.WP page Practical phonetics or a multimedia wikibook​let Practical Phonetic Training would be a great help to many users. But who has expertise, time and courage enough to search and record utterances (audio and possibly video) and start such a page? LiliCharlie (talk) 15:56, 8 February 2015 (UTC)

@RoachPeter: Yes, the recordings being discussed are those in the pages on individual vowels: for instance, the recording in the infobox of Open-mid back unrounded vowel. — Eru·tuon 19:52, 8 February 2015 (UTC)

Thanks, I'll listen to them. Meanwhile, I'll produce an article on Practical Phonetics. RoachPeter (talk) 10:19, 10 February 2015 (UTC)

I noticed that the article on the near-close central rounded vowel [ʊ̈] or [ʉ̞] doesn't have a recording yet. — Eru·tuon 20:32, 10 February 2015 (UTC)

I have submitted a short article on Practical Phonetic Training. At present it concentrates on the historical background to the training and the justification for it, but if it's accepted I intent to add more about current practice. RoachPeter (talk) 09:04, 12 February 2015 (UTC)

Oh, great. I have just read that it has been reviewed and rejected. What is the point? RoachPeter (talk) 08:59, 6 March 2015 (UTC)

@RoachPeter: It's discouraging, I know, but there are a few options that you could pursue. If you submitted the article at Wikibooks, it would not be rejected. Wikibooks does not exclude essays or how-to articles. There is a section of the Linguistics Wikibook on Phonetics that would benefit from the addition of practical information. And if such information is included, perhaps we can find a way to link it from Wikipedia so that readers will find it and use it.

Another possibility is to revise the article in some way to make it less of an essay. Then it would not be rejected as inappropriate for the Article namespace. A third option is to see if it can be added to the Help namespace, perhaps as Help:Phonetics or something like that. Not totally sure if practical phonetics would be appropriate as a Wikipedia help page, but it's worth considering. I know that many readers find IPA hard to understand; hence a practical guide to pronouncing the IPA symbols might be helpful. — Eru·tuon 21:50, 6 March 2015 (UTC)

A fourth and sort of hybrid possibility is to revise the article so that it will not be rejected for the Article namespace, but to also create a how-to page in the Help namespace or on Wikibooks with more details on pronouncing the IPA symbols, understanding places of articulation, etc. — Eru·tuon 21:53, 6 March 2015 (UTC)

Types of transcription

This section was titled "Brackets (and phonemes)"; there was some removal and replacement of the "and phonemes" bit. This latter bit seems not quite right anyway, since the section is neither about "phonemes", nor about "phones" (if that's the right noun for "phonetic"), it is about the distinction between phonemic and phonetic transcription. I changed it to a more generic title; I hope this just about covers the somewhat scrappy bits about "other" brackets. Imaginatorium (talk) 13:29, 30 March 2015 (UTC)

Mid-line tilde not accounted for

Nowhere in this article (nor at Tilde#International Phonetic Alphabet) do we account for use of the mid-line, non-diacritic tilde, Unicode 'tilde' or 'spacing tilde' U+007E, ~ (not to be confused with: the mathematical "similar to" symbol a.k.a. 'tilde operator' U+223C ∼; the diacritic tilde a.k.a. 'combining tilde' a.k.a. 'non-spacing tilde' U+0303, ̃; or the 'wave dash' U+301C, 〜 used in Japanese). This article uses this markup at least once, and it's used many times without explanation at International Phonetic Alphabet chart for English dialects (where it is not even listed in the "Other symbols used in transcription of English pronunciation" table) and in dialect articles like California English.

It is most often used in a way that appears to indicate an intergrading range, e.g. ɑ~ɒ, but may be intended to represent a choice between two exclusive variations rather than a range, or perhaps some specific blending of the two. Sometimes, however, it's used between more than two sounds, as in ɛʊ̯~œʊ̯~œʉ̯~œɤ̯̈~œː~ʌʊ̯, an extreme example from International Phonetic Alphabet chart for English dialects, so a specific intergrade cannot seem to be the [usual?] meaning.

I'm seeing it used inconsistently, with no delimiters, with /.../ delimiters, and with [...] delimiters.

Many of these articles are actually using the U+223C mathematical operator ∼, when they should (surely?) be using the non-maths version, U+007E ~.

24.23.163.55 (talk) 12:07, 18 October 2015 (UTC)

Broken link

The link to "current IPA chart" is broken. 172.56.35.7 (talk) 18:18, 24 February 2015 (UTC) As of 07 December 2015, this link is *still* broken. — Preceding unsigned comment added by ORD89 (talk • contribs) 19:45, 7 December 2015 (UTC)

Disparity between wikipedia consonant chart and official chart

The official IPA chart is here: https://www.internationalphoneticassociation.org/content/full-ipa-chart . The official consonant chart is vastly different to the one presented in this Wikipedia article. What is the justification for having such a disparagingly different chart to that of the official one? — Preceding unsigned comment added by Blimpblam (talk • contribs) 23:54, 16 January 2016 (UTC)

New revision (2015)

https://www.internationalphoneticassociation.org/sites/default/files/IPA_Kiel_2015.pdf --Petreleon (talk) 12:51, 16 March 2016 (UTC)

@Petreleon: Read this: "The 2015 chart makes minor changes to wording and layout, but otherwise reproduces the appearance of the 2005 chart." Love —LiliCharlie (talk) 14:24, 16 March 2016 (UTC)

As the 2015 chart was published under the Creative Commons Attribution-Sharealike 3.0 Unported License I have uploaded it to the Commons and it is now in the article. Love —LiliCharlie (talk) 15:03, 16 March 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on International Phonetic Alphabet. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Corrected formatting/usage for http://www.langsci.ucl.ac.uk/ipa/ipachart.html

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 19:16, 31 March 2016 (UTC)

Criticisms and/or Limitations

Hi. I know very little about IPA but I have a question about this article. The claim is made that IPA is "a standardized representation of the sounds of oral language." (see lede). Well, first does this mean ALL of the sounds? If not, then the sentence is misleading, if so, then I think it overreaches. You can't represent all of the sounds of many "oral languages" with a finite alphabet, can you? Specifically, any two 'similar' sounds having a different representation will have a variable number of possible intermediate sounds between them, which by definition IPA can't capture. This may or may not be relevant - IF it has been shown that IPA is both necessary and complete for the pronunciation for ALL of a speaker's words and sentences. But I doubt this has been done for all of the world's languages. This is objection/question one. Problem two is the well known (if I know it, then it must be well known) difference between a word in isolation and a word in a context. Most words vary in their sound depending on context (leading and following phonemes? blend with the phoneme). This means that there is NOT a unique pronunciation of ANY word. Putting it another way: how well does IPA cover oral languages? Next issue: does IPA extend to any non-Homo language? Its obvious, that it can't cover ANY language with audio signals outside of human hearing, but we have the problem of the difference between vocalizations and hearing, I'm not sure the former is a subset of the latter or do both sets have disjoint elements? (ie. there are vocalizations which can't be heard and, more obviously, sounds which can't be vocalized). If it is true that some languages include sounds which are NOT represented by the IPA, then this should be noted up-front. Same with IPA+Extension. Anyway, I am under the impression that the electronically recorded signal of oral language is the only accurate "representation" of what was said. IPA is clearly NOT that. (Nor is it the perceived sound, but that is impossible (afaik) to determine.) My point is that this article lacks a discussion of the qualifications and limitations of the IPA, which are surely known to some extent (my guess is to a pretty good extent). Other questions involve its use in non-IndoEuropean cultures. Do Chinese speech pathologists use it in their publications, for example? Is "attack" part of IPA "intonation"? How well are duration, vocal fry, nasal, and other influences captured? Its too bad that an expert isn't available for editing, but surely the science/engineering design of electronic voice synthesis MUST have a great deal to say about this, and surely a lot of that has been written and is accessible.216.96.79.108 (talk) 22:13, 24 September 2015 (UTC)

Hello 216! Let me try to answer your questions one by one:

All sounds

Yes, that's what it means in the sense of all sounds that make sense to distinguish. There are in fact diacritics that can be used to distinguish intermediate sounds, in the few cases when that is necessary. That said, there are some distinctions that are not standardized yet; this typically happens when a linguist researches a language and finds that a distinction is meaningful in a language that has not found to be meaningful before. That's why I wouldn't write "all" in that sentence. But, yes, it is possible to represent all sounds of oral languages with a finite alphabet.

Context

Yes, pronunciation of words varies depending on context. That can be covered by IPA without a problem, but it doesn't have to be, and is not necessary for most standard situations. Whether to do that or not is not part of the standard, any more than it is whether you write A♯ or B♭ in standard musical notation.

Non-human languages

IPA is not intended for those.

Non-European languages

If you read the article, you can see that those are covered with IPA. While IPA was not devised for speech pathologists, I see no reason to assume that IPA can't be used by Chinese speech pathologists.

Electronically recorded

No recording, whether electronic or analog, is completely accurate. Neither is any notation system, either. That holds for language just as for music. It is a general limitation that has nothing to do with IPA in particular.

How well are ... captured

Well enough for the purposes listed in the article. Also, please note that "representation" does not necessarily mean "capturing".

Voice synthesis aspects

IPA does not claim to be a complete system to contain all information needed for voice synthesis.

Attack

Not sure what you mean by "attack". Are you referring to the term used for ADSR envelope? Would you have an example for when that is a relevant distinction for spoken language that is not already inherent in the distinction between initial consonants?

Your main point seems to be that you miss coverage of limitations in the article. Your examples cover limitations that are par for the course; they remind me of someone demanding that a motor vehicle article should cover the fact that a car can't (normally) fly. If you have any specific sourced information on limitations (especially for the "how well are ... captured" questions), you are cordially invited to add that. I'll be happy to help you with that. — Sebastian 17:36, 28 September 2015 (UTC)

I think Sebastian answers the question fairly well, but I'd qualify the answer somewhat. It is true that the IPA uses a finite set of symbols to represent points on an infinite space. For instance, there are more possible points between a high-front vowel and a high-mid front vowel than can be represented using the tools of the IPA. But this doesn't matter, because you only need enough symbols to distinguish the sounds that the world's languages distinguish. There's no language, for example, that distinguishes ten different vowels between [i] and [e], so the IPA doesn't need a means of making that many distinctions. Of course this means that the same symbol may represent slightly different sounds in different contexts. The symbol [r] (even if in square brackets) should not be taken to represent precisely the same sound every time it's used. As Sebastian says, if you need to make a finer grained comparison of two given sounds, you have diacritics to help you out. In any case, I think what the anonymous poster is pointing out is that no IPA representation of speech, however detailed, could provide enough information to allow the original speech to be played off. But that's not what's meant by "a standardized representation of the sounds of oral language." What's meant is that you have all the tools you need to distinguish the sounds of the world's languages, and that's pretty accurate. Garik (talk) 02:11, 29 September 2015 (UTC)

But also, the OP's reference to audio recordings completely misses the point. A transcription of a language is there to capture generalisations: so when a young girl says [ˈzdrastvʊjtʲə] (or /bɔ̃.ʒuʁ/) in a high shrill voice, speakers of Russian (or French) recognise this as "the same as" a gruff male growling [ˈzdrastvʊjtʲə] (or /bɔ̃.ʒuʁ/), even though the audio recordings would be utterly different. Imaginatorium (talk) 13:13, 29 September 2015 (UTC)

Precisely. Garik (talk) 13:20, 29 September 2015 (UTC)

Thanks for your helpful and thoughtful responses! Am I wrong in thinking that in order to match an audio recording of a single "word" to a specific IPA expression that all three of the following requirements must be met?

1. The IPA representation must explicitly or implicitly be tagged with the language it is encoding.

2. The listener/reader must be proficient in speaking that language.

3. The listener/reader must be proficient in using IPA specifically FOR THAT LANGUAGE.

I've seen several sources that make the claim that a given IPA symbol string is generally NOT unique unless the language is specified. I've also seen several sources which claim that there are nuances which are NOT captured by IPA and which require a proficient speaker of the langugage to decode from the IPA symbol string into a word/sound. I think that I'm not alone coming to this article thinking that IPA is an unambiguous way to encode the oral languages of the world, and it is not. If I understand correctly, two IPA experts may disagree when given the same symbol string. (I assume they could also encode the "same" word sound with significantly different strings). If I'm correct, then I think the lede should state that. Specifically, that IPA is language dependent and it may not fully encode a given oral word. It may or may not be helpful to point out that Wikipedia (en) points to the English IPA table (rather than "THE" IPA table). Oh, it may also be worthwhile to mention that no general IPA to sound algorithm exists. (Which is what I came looking for, originally.) Thanks again!216.96.77.183 (talk) 18:49, 7 November 2015 (UTC)

"The IPA" itself is completely untied to languages, so it makes no sense to say it's language-dependent. It can sometimes be used in language-specific fashions, such as when using it phonemically (and not phonetically). That the IPA may not fully encode a given oral word is not the same thing as it being language dependent. It can't fully encode a given oral word simply because it's not a recording: only a perfect sound recording can achieve that. The IPA only provides an abstract representation of sound. An IPA-to-sound algorithm could in theory certainly exist, and in fact, there are certain speech synthesizers that come close. It would not, however, sound exactly like a native speaker of any language.

And to address your three points explicitly:

1. No, in a phonetic IPA representation, there is no need to explicitly or implicitly specify a language; it could even be gibberish not in any human language, and yet it could be spoken from the IPA representation. This is not the case with a phonemic representation, though, which a language does need to be associated with.
2. No, someone can read a phonetic IPA string if they are proficient in IPA, although of course, they may not be able to read it as quickly and fluently as someone who knows that string as a word in a human language.
3. No, same as above.

LjL (talk) 19:01, 7 November 2015 (UTC)

I have a criticism: IPA is incredibly hard to learn for beginners. Even though that is really hard to fix, I thought I might put that out there. NewbTopolis Rex (talk) 01:28, 29 March 2016 (UTC)

We all started out as beginners. That's no argument. It's not harder than learning a new language with different spelling rules. --2.245.154.109 (talk) 00:51, 23 July 2016 (UTC)

xʷ̜

The second example of less rounded, ◌̜, is "xʷ̜ ". Is this right? Should the diacritic go under the "w" or the "x"? Jimp 04:11, 15 April 2016 (UTC)

Under the w. [x] isn't rounded to begin with. — kwami (talk) 06:52, 23 August 2016 (UTC)

On including IPA charts that are not the IPA chart

We've long included a chart that is the concoction of one single WP editor -- a clear NOR violation, in my opinion. As of 2015, the IPA chart is distributed on a public licence in fully accurate form. So really, now is the time for us to go with just that single chart, which definitionally is the IPA. (N.B.: we include extensive discussion of alternative symbols elsewhere on WP.) I hope the editor who created the concocted chart will understand. BrucePHayes (talk) 20:23, 16 March 2016 (UTC)

@BrucePHayes: I take issue with one point: The IPA is not the IPA chart. It's the set of symbols that the chart summarizes. This is easily demonstrated by the IPA Handbook, which uses symbols that are not included on the chart but can nonetheless be understood by anyone who recognizes that the chart is merely a summary of the IPA.

Part of the rationale of the official IPA chart is to save space so it all fits on a page, and students are often mislead by the compromises needed to accomplish that. So e.g. students often think epiglottals, alveolo-palatals and the lateral flap are not regular pulmonic consonants because they don't occur in the pulmonic consonant section of the chart, when the actual reason they're not there is that we'd need a smaller font size to accommodate the extra rows and columns and that would make the chart harder to read. And then there's tone: if you took the official chart at face value, you'd think it listed the tone letters of the IPA when in fact it only provides a sample. (Unless you're going to argue that the IPA is truly so deficient that it is incapable of transcribing a mid-falling tone!) This has practical consequences. For example, IPA Braile only distinguishes those tones found on the IPA chart and thus is not able to transcribe the IPA Handbook without recourse to nonce symbols. This article is not about the IPA chart, it's about the IPA, and a little variety in our approach may be needed to adequately convey that topic. — kwami (talk) 07:15, 23 August 2016 (UTC)

Thank you for your courteously worded remarks. If I could make a few points in reply:

• It is true that the IPA is not the IPA chart. The International Phonetic Association also provides its Handbook to provide additional information on what the symbols mean.
• As a phonetics teacher, I want my students who visit this article to encounter legitimate, authentic information about IPA transcription, which will reflect what the Association says about it. I do not want the novel creations of WP editors to appear, since they are likely to be mistaken by my students for authentic IPA. The Wikipedia policies of WP:NOR and WP:VER are plainly relevant here.
• Those interested in reforming the IPA (addressing, perhaps, the issues you raise), should join the Association and lobby from within. Everyone is free to join and the dues are not that substantial.

Sincerely, BrucePHayes (talk) 20:32, 23 August 2016 (UTC)

@BrucePHayes: The IPA chart of consonants on this page was not the work of one editor. See Template talk:IPA consonant chart for the related discussions, including the one that led to the addition of affricates. — Eru·tuon 18:40, 24 August 2016 (UTC)

Yes, and there are no reforms to the IPA in that IPA chart. The changes are only in how the chart is presented, and that's not a matter of OR. E.g., including pulmonic consonants in the pulmonic-consonant section of the chart, or noting that the sample of tone letters is only a sample, provides clarity to our coverage of the IPA and in no way affects the IPA itself. (Except for the greyed-out letters, though most of those are now included in the 2012 extIPA.) It's also clear from the section title that this is not the presentation of the chart by the IPA. — kwami (talk) 04:22, 27 August 2016 (UTC)

IPA for beginners?

How do I make a pronunciation guide with the IPA? No, I'm serious. I can't figure out some of the sounds, the sounds on the website are annoying, and they are confusing because it's never just one sound. Is there a way to make this page easy to understand for people who have very little clue what the IPA means or how to use it? NewbTopolis Rex (talk) 01:19, 29 March 2016 (UTC)

I'm not sure what you want to achieve. Maybe you can consult Help:IPA for English first, then move on to Help:IPA. If you want to learn IPA more thoroughly you won't be able to do so by imitation alone, but will have to learn to control the movements of your speech organs (see Articulatory phonetics and Some low-tech means of observing your articulators). Ian Catford's A Practical Introduction to Phonetics is a very helpful reader with "experiments" for self study, though I recommend the help of a teacher. — As to your proposal to change this page please read WP:NOTHOWTO. Love —LiliCharlie (talk) 02:14, 29 March 2016 (UTC)

@NewbTopolis Rex: Which language are you trying to make an IPA for? Is it for English or some other language? --BrianJ34 (talk) 04:44, 12 November 2016 (UTC)

Potential list article

Main page: User:Sweyn78/IPA charts

I was hoping to create a list article for IPA charts, to make it easier to grab symbols without having to scroll through a long article. I apologize if using a subpage wasn't the correct way to do this. Can the article (International Phonetic Alphabet/Tables) be moved somewhere where it would be acceptable? /ˈswɛ̹͡yn/78 23:19, 11 September 2017 (UTC)

There is a spot below the edit box that has an IPA feature. You can even click on the characters to insert them, no C&P necessary. Is there something missing from this? — Ƶ§œš¹ _{[lɛts b̥iː pʰəˈlaɪˀt]} 23:26, 11 September 2017 (UTC)

I was unaware of this feature until you mentioned it. It's good to have; thanks! TypeIt's full IPA keyboard is also nice for IPA input.

There are reasons besides input for an IPA list article, though. It would provide a quick reference of the entire IPA, akin to File:The International Phonetic Alphabet (revised to 2015).pdf, but with the full power of MediaWiki markup. The closest thing we have at the moment is Template:IPA consonant chart, but it only contains consonants, and I don't think most people realize they can visit templates directly.

/ˈswɛ̹͡yn/78 00:03, 12 September 2017 (UTC)