Rahul, your proposal is related to

Bug 46610 - Pronunciation recording tool

Please announce it there. Thank you!

rahul14m93 wrote:

I am sorry 2 tabs opened at the same,causing some confusion!

One year of silence. Setting to Lowest only to reflect the current reality, which is that nobody we are aware of is working or planning to work on this.

Is this a duplicate to T2224? They seem to want to achieve the same thing, but are expressed in different ways.

A) Awesome! I requested this in 2010! :D
B) There were some concerns raised at the time, about issues with dialect variance. See a brief explanation in https://en.wikipedia.org/wiki/Help_talk:IPA/Archive_2#Embedded_IPA_pronunciation_soundfiles
I imagine the rabbit hole goes deeper though, but I have no expertise in this area.

Sidenote, not already mentioned above, so see also https://en.wikipedia.org/wiki/IPA_pulmonic_consonant_chart_with_audio and https://en.wikipedia.org/wiki/IPA_vowel_chart_with_audio

Converting IPA to speech using lexconvert's correspondences to eSpeak phonemes and eSpeak seems to yield reasonable results (at least for the sampled English Wikipedia entries that have IPA).

To try, paste the IPA into the text box at https://itinerarium.github.io/phoneme-synthesis/.

Perhaps, some scripted process can run

python lexconvert.py --try unicode-ipa "/mʊmˈbaɪ/"

and upload/attach the output with some mechanism to flag low-quality output for review?

Alternatively, humans could QC the pronunciation using the demo site or some custom tool to streamline the copying/pasting and only save/upload those entries that sound reasonable?

I can see if I can hack something up if there's consensus that this is worth trying, and has a chance to be added to Wikipedia as a default feature. Is there agreement that automated IPA pronunciation, based on lexconvert + eSpeak as demonstrated above, is beneficial (i.e. good enough that it's better to have it than not to have it)? If so, what's the best way to deliver a proof of concept?

The implementation options are:

• use the existing JavaScript code (linked in T33221#2915772) which requires minimal effort but requires the client to load 2 MB to play it back (can be cached client-side).
• use a bot that generates and uploads individual pronunciation files
• provide an API that generates and caches pronunciations for IPA strings.

I've created a quick hack using the client-side JavaScript (first option listed above). gzip compression brings the JavaScript down to under 500 kB. Using WebAssembly could likely improve it further but that would require more effort.

If you want to try it, add the user script to your user script page, visit a page containing IPA and click the small blue "play" arrow that should show up next to it.

This is really cool!

There's some room for improvement with some of the pronunciation — I tried it out on the classic example of "Nevada", where the middle 'a' didn't quite match the expected 'a as in bad', and I tried "Barack Hussein Obama", where it kind of garbles the end of Hussein — but even as is, it would be a pretty big usability improvement for most users who can't make sense of the IPA markings.

This definitely seems like it would be worth polishing up and intergrating into the default experience, and iterating on.

This would be a useful tool for sanity-checking listed IPA pronunciations (e.g. if the examples @Ragesoss tried out above, messed up because of incorrect transcription into IPA, having a machine reading would let that issue be identified and corrected). However, this could also serve to motivate more people to make and upload actual pronunciation recordings, if they are dissatisfied with the machine pronunciations for some reason (again, Ragesoss's above examples are relevant).

Speaking more speculatively, this could also ultimately serve to inform work on a hypothetical revision or successor to IPA, by exposing and highlighting shortcomings of the extant system (of course, this is where I betray my ignorance of IPA in general).

I'm happy to address the technical part of this, but not the organizational part (finding decision makers, getting a yes/no, deciding in which shape this should be implemented).

The village pump discussion mentioned that another text-to-speech project (Wikispeech) exists, and the relevant decisions have already been made long ago. They're aiming for a server-side version (which will be more work but may also result in a better/faster experience for the user) and a much bigger scope (actually read articles vs. just IPA).

I've built a slightly improved version that runs from a bookmarklet. This solves my personal problem. And while I'd love to make it available for everyone and I'm happy to volunteer my time to do technical work to polish it, unfortunately I don't find the organizational work pleasant nor rewarding, and can't bring myself to spend my free time on it (especially since I don't want to create a conflict with the Wikispeech team).

If someone is able to get an "official" decision that client-side IPA TTS is something that should be included in Wikipedia by default, and some way for me to get answers to questions regarding the desired implementation specifics (e.g. whether this should be an extension/standalone code/..., level of sandboxing, level of compatibility with legacy browsers, ...), I'm happy to do the technical part.

This seems like basic and expected functionality.
I wonder how @alexhollender thinks this might impact the reading experience?

Related: @DLynch shared this IPA conversion tool with me: https://itinerarium.github.io/phoneme-synthesis/

Possible merge in from T298950

https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2022/Reading/IPA_audio_renderer

also, it would be really nice if you could play the audio without being re-directed to a different page : )

@alexhollender_WMF That would be T229169: Support inline links to audio with ability to play it in situ.

It seems at one point this was somewhat working, and now it is gone again -- is this a dead ask?

I don't recall that we ever (widely) enabled the text-to-speech part of Phonos (unless you're referring to something else that was "somewhat working"?)

Widely, nope. It was certainly working inline on test at one point (I demoed it here: https://test.wikipedia.org/wiki/User_talk:Xaosflux/phonos) - for somewhat arbitrary IPA-->phonos-->sound ,but that is disabled now.

I don’t think it is a dead ask.
But Phonos TTS is something that was provable more difficult than expected, which led to the cancellation of the implementation that was being worked on at the time.

This might still be implemented at some point, but I think:

1. Not automatically for IPA
2. Not without supporting multiple dialects easily (so en-GB and en-US).
3. Not without increasing voice qualities in open models.

There’s also WikiSpeech, but in my opinion it is overly complex and it has been in development for 10 years now. So more evidence that this is harder to do (at the quality level that Wikimedians want it) than can be facilitated right now.

Yes, Phonos ended up as an inline audio player (which is pretty useful!), after it became apparent that IPA is not an expressive TTS source format.

The above thread mentions a tool for recording, and of course this now exists in the form of the wonderfully capable Lingua Libre: https://lingualibre.org/ — to my mind, that approach is more in keeping with the wiki way.

"a tool for recording" being "the wiki way", wait you mean having to manually make recordings and manage audio files locally as opposed to text entry and dynamic presentation of text? Am I missing something in that strategy?

having to manually make recordings and manage audio files locally as opposed to text entry and dynamic presentation of text?

No, I mean having humans create content that is accurate and serves the purpose of explaining how something is pronounced. It seems that it's the unusual stuff that the machine-generation fails at, and that's exactly where it's most needed. Certainly it'd be nice if we could have a text format that would make this easy, but it seems that we don't yet. I was just linking to Lingua Libre for completeness' sake, because this thread mentions the idea of a tool for recording. I mentioned "the wiki way" in a light-hearted sense, a sort of nod to the non-overly-technical solutions sometimes being our preferred ones.

Also for completeness' sake, I'd be curious to know what kinds of edge cases IPA fails to support. AFAIK IPA has various levels of precision, starting with the phonetic vs. phonemic transcription modes (aka [...] vs. /.../) and the former supposedly is able to capture significantly more detail than the latter. So is the limitation inherent to the syntax (source format) level, or does it lay at the ability of TTS engines to correctly represent such nuances?