[WikiEN-l] Pronunciations and IPA/SAMPA

Fri Sep 5 09:00:25 UTC 2003

David Friedland wrote:

> In fact, there is. The International Phonetic Alphabet is ideally 
> suited to marking pronunciations of words, and is flexible enough to 
> describe broad transcriptions that represent how a word is pronounced 
> in multiple dialects to minute phonetic details. This wisdom, of 
> course, has been lost on the makers of most American dictionaries, who 
> each insist upon using their own ad-hoc pronunciation scheme (one of 
> my personal pet peeves). The _Cambridge Dictionary of American 
> English_ is a notable, if perhaps not well-known, exception. The 
> foremost dictionary of (mostly) British English, the _Oxford English 
> Dictionary_ uses IPA, as does the major Australian English 
> dictionary,  _The Macquarie Dictionary_.
>
> I see the following possible solutions (in the order that I think is 
> good):
>
> 1.) Auto-detect the browser and send IPA Unicode to browsers that 
> support it and TIPA LaTeX images to those that don't. (Pros: 
> attractive display of IPA for all users. Cons: lots of  programming)
>
> 2.) Just send TIPA LaTeX images (Pros: attractive display of IPA. 
> Cons: Uses images in text when for some users embedded IPA Unicode 
> would look better)
>
> 3.) Store the IPA in a special format or in a special tag, auto-detect 
> the browser and send IPA Unicode to browsers that support it and SAMPA 
> to the rest. (Pros: doesn't require inserting images or using TeX. 
> Cons: SAMPA is ugly and hard to read)
>
> 4.) Render IPA into GIFs or PNGs and just insert them as images. 
> (Pros: compatible with everything. Cons: time-consuming, and difficult 
> to change)
>
> 5.) Devise a Wikipedia-specific pronunciation scheme and just use that 
> (blech!) (Pros: no coding required. Cons: YAAHPS (Yet Another Ad Hoc 
> Pronunciation Scheme))
>
> 6.) Do nothing and continue to allow people to use ad-hoc 
> pronunciation schemes (BLECH!!) (Pros: no action required. Cons: 
> maintains status quo harms as described above) 

I've snipped your message, but it was all extemely well put :)
ad-hoc schemes are a peeve of mine too.

I'm opposed to options 5 & 6 :)
My opinion on the matter so far has been to stick with SAMPA until we 
can do something about using IPA.
We could stick to SAMPA in wiki source text, since everybody can edit 
it, and tag it. Then browser-detect and send IPA text / IPA in PNG 
depending.

A smart thing to do if the renderer knows about SAMPA would be to 
automagically provide a link to the SAMPA or IPA key.
eg:
/sampa/k{t/
turns into some IPA which if clicked takes the reader to the explanation 
of tehe symbols.