# Talk:International Phonetic Alphabet

International Phonetic Alphabet has been listed as one of the Language and literature good articles under the good article criteria. If you can improve it further, please do so. If it no longer meets these criteria, you can reassess it.
Wikipedia Version 1.0 Editorial Team / v0.7
This article has been reviewed by the Version 1.0 Editorial Team.
This article has been selected for Version 0.7 and subsequent release versions of Wikipedia.
 GA This article has been rated as GA-Class on the quality scale.
WikiProject Linguistics / Phonetics  (Rated GA-class, Top-importance)
This article is within the scope of WikiProject Linguistics, a collaborative effort to improve the coverage of Linguistics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
GA  This article has been rated as GA-Class on the project's quality scale.
Top  This article has been rated as Top-importance on the project's importance scale.
WikiProject Writing systems (Rated GA-class, High-importance)
This article falls within the scope of WikiProject Writing systems, a WikiProject interested in improving the encyclopaedic coverage and content of articles relating to writing systems on Wikipedia. If you would like to help out, you are welcome to drop by the project page and/or leave a query at the project’s talk page.
GA  This article has been rated as GA-Class on the project's quality scale.
High  This article has been rated as High-importance on the project's importance scale.
 See Wikipedia:Manual of Style (pronunciation) for the style guide on the English Wikipedia regarding the use of IPA symbols.
This article has been mentioned by a media organisation: "What IPA stands for.". The Star (Malaysia). September 8, 2004. ()

## Labiodental nasal

"The labiodental nasal [ɱ] is not known to exist as a phoneme in any language.[27]", but in the labiodental nasals article, it is said to be used in many language. Or it that not as a phoneme? Sounds strange.

That is probably the case (that it is there but not phonemic). That is the case, at least, for English. rʨanaɢ (talk) 14:47, 18 February 2011 (UTC)
Like as an allophone of [m]. Dan 14:49, 18 February 2011 (UTC)
See Labiodental nasal. — kwami (talk) 14:59, 18 February 2011 (UTC)

It is used in English in words like symphony. Signing for archive: -DePiep (talk) 00:51, 19 November 2013 (UTC) User:Example 14:60, 18 February 2011 (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/fonipalfdder 16:20, 11 April 2014 (UTC)

## 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 (HTML: &#10216;), U+27E9 mathematical right angle bracket (HTML: &#10217;) 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 $option • One other route could be tried: {{math}} formulae rendering: $\langle abc \rangle$ [example 1]. ([itex]\langle abc \rangle$, 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 [itex]-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).
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 (HTML: &#9001; &lang;), U+232A right-pointing angle bracket (HTML: &#9002; &rang;). 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 and U+232A of Unicode 1.0.0 would indeed be perfect, but Wikipedia seems to convert them to the East Asian fullwidth punctuation characters U+3008 and U+3009 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.

Math-A Misc. Tech
character itself code entry {{angle bracket}} template &lang; + &rang; code entry

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 [itex] again. -DePiep (talk) 16:38, 17 November 2013 (UTC)
Has anyone asked [itex] 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" /> x <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" /> X <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 ToolsFont 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)
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 [itex]. 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)

## 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 (talkcontribs)

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)

## 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͍͎ ]?

## 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)