Extension talk:PronunciationRecording/GSoC 2013/Proposal

Thoughts
This looks like a good proposal. I had a couple thoughts. I'm not sure the CAPTCHA is necessary. I doubt that many people will go to the trouble of recording bogus pronunciations. I think it's simpler to have numeric codes. The first has no code or just -1. The second has -2, etc. Superm401 - Talk 20:25, 5 April 2013 (UTC)


 * Sure ill be removing the captcha thing,seems redundant to me now and the small problem i feel is that using webRTC the the pronunciation file that will be downloaded is in the .wav format.So in order to upload it to wikimedia commons i need to convert it into .ogg,i am little stuck on this conversion thing .Thanks for replying--Rahul21 (talk) 14:09, 8 April 2013 (UTC)
 * If you happened to use a CAPTCHA you should just integrate it via Extension:ConfirmEdit. --Nemo 07:55, 10 April 2013 (UTC)

Noise filtering, and trim start/end silence
Perhaps as a later phase of this project, optional noise filtering would be good. I always use the Noise Reduction command in GoldWave after recording a pronunciation, and it makes it a lot clearer. Also are you going to trim any periods of silence at the start and end? 86.164.200.121 15:47, 8 April 2013 (UTC)


 * Yes its a good feature that can be implemented as a spin off extension.Suggestion Noted --Rahul21 (talk) 08:03, 9 April 2013 (UTC)

List
If I were to record pronunciations, I would record a list of words all at once. E.g., the user provides a list of words (or phrases), and the recorder then asks to record each item one after the other (the pronunciations can be saved progressively or at the end, I don't know what is the best option). This would be much easier than recording every word individually. To give a concrete example, I don't want to record all the forms of this verb separately (although they will end up in different files). Same for categories and other lists. Darkdadaah (talk) 18:07, 8 April 2013 (UTC)

Translations
Do not forget to make the tool so that it can be translated and used in other languages (cf Translatewiki.net). Darkdadaah (talk) 18:09, 8 April 2013 (UTC)


 * Translations wont be an issue ,since the recorder will be specifying the which language is he recording in Example:If the User is recording "English(US)" then it will be specified in the metadata--Rahul21 (talk) 08:09, 9 April 2013 (UTC)
 * He means localisation of the extension interface. --Nemo 07:55, 10 April 2013 (UTC)
 * Yes. The interface should be translatable so that the tool can be used in other projects than en.wikt. Darkdadaah (talk) 11:52, 10 April 2013 (UTC)

Words with different pronunciations
Do not forget also that in one language a word can be pronounced differently. E.g. en:read in English. The name of the file should reflect that. Darkdadaah (talk) 18:13, 8 April 2013 (UTC)


 * For such words i plan to save them like en-read-1.ogg ,en-read-2.ogg,etc.So under the umbrella of a word,same words with different pronunciations can be saved

getUserMedia audio works?
Does getUserMedia for audio actually work already? I've not been able to get it to receive any audio on any browser. None of the demos have worked for me. Is this just on my end? --Yair rand (talk) 21:47, 8 April 2013 (UTC)


 * getUserMedia has very low browser support as off now,but since the extension will take 6-7 months to get deployed ,its highly possible that by that time the compatibilty issues are solved --Rahul21 (talk) 08:06, 9 April 2013 (UTC)


 * [https://code.google.com/p/chromium/issues/detail?id=112367#c178]--Rahul21 (talk) 08:13, 9 April 2013 (UTC)

wikt:WT:EDIT
wikt:WT:EDIT is a framework used on the English Wiktionary for conducting edits outside the edit screen. If the tool is also going to have a feature to add the uploaded audio to the entry immediately, I suggest using this, to simplify the workflow on the user side. --Yair rand (talk) 21:53, 8 April 2013 (UTC)


 * I havent thought of this ,will take a look and get back to you ,Thank You
 * Note that this is only used on en.wikt. Don't make it dependent on that, otherwise the other projects will not be able to use this tool. Darkdadaah (talk) 11:51, 10 April 2013 (UTC)

immediate feedback
As I understand the proposal (and as would be necessary IMO), the submitted file would not be added to the Wiktionary entry. The submitter may be frustrated by that. Immediate feedback would be necessary in the entry indicating the file's been submitted. Preferably, the "record this word" prompt should be replaced by a "oops, recorded that wrong! delete and try again" prompt.—msh210@enwikt 04:24, 10 April 2013 (UTC)


 * In mediawiki when we save an article we get a message "Your edit was saved" .If the file was succesfully not uploaded perphaps we could use a messae "Upload not succesfull".Kudos--Rahul21 (talk) 09:55, 10 April 2013 (UTC)

Choosing language and way to include the tool in pages
I hear that an idea is making the user input in what language the word is being recorded. Ideally, this would not be needed, and the tool would already know it: to do this, however, the language should be fetched from somewhere, and it's not trivial because entries can have many languages, see e.g. go (and any language can have different words written in same way but pronounced differently, i.e. heteronyms). A solution may be: show the tool where called with an explicit function with the required info, e.g. for English which defaults to PAGENAME. This would also make the tool opt-in and less controversial; e.g. en.wikt would add this call to templates such as en-verb if they want it, and so on. --Nemo 07:55, 10 April 2013 (UTC)
 * On heteronyms: if the function also managed to change its effect after recording, i.e. to (stop offering recording and?) embed the recorded file on the page, the recording would just have an incremental numering, but the tool would embed the correct audio file in the correct section of the page (the same one it came from). --Nemo 08:29, 10 April 2013 (UTC)

Feasibility of encoding or uploading as .WAV
I really like this idea but many recorders will output formats unsuitable to upload to Commons. You could: Now 3 seems like the easiest technically but the most difficult politically. Perhaps the conversion could be done on the server before the file is 'uploaded', then you would not need to convince the Commons community of very much, as the site would not be hosting a proprietary format. It may be the case that .wav is a less objectionable format than people think, and Commons may find it in its heart to treat it as it does .gif? Let me know what you think, I will pitch something on the Commons VP and see which way the wind is blowing Moogsi (talk) 00:21, 11 April 2013 (UTC)
 * 1) Find another solution outputs .oga
 * 2) Perform the format conversion on the user's side (firefogg? media.io?)
 * 3) Convince Commons to accept .wav uploads (this goes against the philosophy of the site (i.e. no proprietary file formats)

We have extension's like TimedMediaHandler which work on server side transcoding
 * Well I had a talk with many people regarding this .Since this extension will take 6-7 months to get deployed, by the time we will be trying to convince commons to grant us permission for .wav. If we dont get permission by the end, we will resort to server side transcoding
 * Why do we need .wav exactly? Are ogg files not good enough? And if we really need lossless formats, is there no better format (e.g. flac)? Darkdadaah (talk) 08:18, 11 April 2013 (UTC)