Technically speaking, this can be easily implemented since T212580. But we must first think about how to integrate this option to the UI without overloading it.

I'm facing the same 500 internal error on a MediaWiki instance I'm working on. I understand the reason of this 1Mio limit, but this should be at least configurable in the LocalSettings to allow non-Wikimedia wikis to adjust it depending of their need.

@Mh-3110 that sounds great, I can't wait to see :).

Done in the commits dc6538b5, d3571387 and 39ca9e92.

I've just added the defaultsort to the template for manual categorization to also benefit from the sortkey.

tl;dr: A new API endpoint which runs a tricky MySQL query on the database should do the work.

@Yug the real issue here is not the way to compare history and current session, it is how to get efficiently (= in a way that will handle nicely a load rise) the recording history of a speaker. Storing everything in a wikipage is a good idea, but (as I said in my first comment), it will produce many edge-cases and desyncs to manage. For example, during a recording session, if we save the history page before sending the files to Commons and a crash occurs, we would end up with words in the history that arn't on Commons. And reverse, if we save the history page after sending the files to Commons and a crash occurs, we would have files on Commons that arn't in the history.

@MichaelSchoenitzer Yes, it could definitely be an option as it is really quick, but again we have a limit issue : the number of triples returned is limited to 100 by request. So each request is fast, but we will have to do several dozens of them to get all the data we need, loosing a lot of time in network discussions. I've dug the subject a little bit but didn't see any way to configure this limit server-side, is there any ?

In fact, the Template:Lingua Libre record (which is used by all the files uploaded using Lingua Libre) already add the transcription as a sortkey to the Category:Lingua Libre pronunciation-XXX.

This approach seems interesting. But if we decide to change the categorisation that way, we should start using BCP47 tags instead the ISO-639-3 language code everywhere else for consistency. As it will be a major change, I'll make a RfC on LinguaLibre, to be sure there is no opposition.

@Kvardek_du: Tu m'as mal compris je crois, je ne parlais pas de l'ajouter dans les conditions générale mais à l'endroit de la flèche rouge sur la capture ci-dessous, à la fin de la seconde étape du RecordWizard.

I just said above that it should be possible now to use a SVG (and the current image is the biggest PNG we can have as a logo).

This was historically impossible on MediaWiki, but since REL1_31 it should be now using $wgLogoHD (ref).

See this commit.

Solved several months ago, just a temporary issue during a deployment.

Hum, in fact, even if Lingua Libre Bot didn't add the audio recording to Wikidata and/or Wiktionaries, any contributor can add manually the audio recording to those projects as the file is stored on Wikimedia Commons.

The RecordWizard-related user options will from now on be stored in a RecordWizard.json user subpage ([[Special:MyPage/RecordWizard.json]]).

This could be a cool feature, but I fear all technical implementations will be ressource-expensive and time-consuming. So before choosing a solution, we should test its scalability.

Technically it would be pretty easy to do. But two workflow-related questions came into my mind when thinking about this feature:

1. What should we do from the "play" icon-button added next-to each word before the word is recorded?
2. If the user listen to an audio recording without a headset while the recorder is working, this one will detect the sound and make a new unexpected record.

As @Lea_Lacroix_WMDE pointed out, this has been done during last week hackathon. See the new "External Tools" word list generator: https://lingualibre.fr/wiki/MediaWiki:Gadget-ExternalTools.js.

The creation of the daily datasets solve this request I think (https://lingualibre.fr/datasets/).
@Unuaiga: Please reopen this task if not.

@Yug: This is unrelated to installing mediawiki extensions. MediaWiki (ans thus Lingua Libre) support the display of svg files, even if the upload of svg files is disabled locally. In fact, Lingua Libre is not meant to host files like images; for that, there is Wikimedia Commons. And after a quick search, your icon is already there: [[File:Font Awesome 5 solid microphone-alt.svg ]] (https://commons.wikimedia.org/wiki/File:Font_Awesome_5_solid_microphone-alt.svg).

@Yug: I've reverted your change, because SVG are natively supported by MediaWiki, no need of an additional extension.

Sure you can work on this, your help is really appreciated :).
There is only one blocker, it is not easy yet to setup a development environment for Lingua Libre, but I'm currently on it, and it should be ready before Saturday. I don't know if you're aware of it, there is a LinguaLibre hackathon organised this week-end at Wikimedia France's office. If you want you can join us!

@Tgr thanks for the review and the merge!

@Jnanaranjan_sahu The $this->config parameter send to makeCurlCall in 5th position on line 253 in the initial version was useless, this method was only taking 4 parameters. In fact, makeCurlCall can access by itself to $this->config because it shares the same instance of the Client class with makeOAuthCall (as you can see on the lines 276/279 of the initial version).

I've already seen this issue in the past, but never figured out it's origin.
A 500 is returned when switching the language interface to occitan (oc), but it works well with every other languages I've tested, so I'm a bit confused.
I'll investigate this in more details during the comming weekend.

The Upload2Commons extension seems to be malfunctioning since the upgrade from REL1_30 to REL1_31. It defines two new user rights, "remoteupload" (to upload any files to commons) and "remoteuploadown" (to upload your own files to commons). By default, basic user only need the second to use the RecordWizard, only administrator had the first right. But since the upgrade, the extension asks for both rights to be set.

Thanks for the report.

Done in commit a0e71c4. Pressing the [del] key will reset the currently highlighted item.

Just to be clear, what you want is to delete the audio record attached to an item, but not the item itself, am I right?

Done in commit ce40907.

I've absolutely no idea where this title duplication comes from... As a temporally fix, I've added this peace of code to the global CSS to hide the second titles:

.page-Special_RecentChanges h4 + h4 {
    display: none;
}

No idea if this makes sense / is in scope

Yes it is :)

In the LinguaRecorder library, when switching from the listening state to the recording state, we had to disconnect a first ScriptProcessorNode (see doc) and then connect the second one. If some audio sample arrived in-between, they got lost, creating the small audio breakout. To avoid this, I now use only one ScriptProcessorNode (which also simplifies other functions, because we no longer need to manage node disconnection / reconnection in many places).

See this commit.

I've made a first try by implementing somehow the second solution: A buton allowinf the user to record one word, which will be played one second later. Lets see how users will react.

Done in this commit.

the slash in the word seems like the obvious candidate

Yes it is the cause of the warning, the filename mentioned is a proposal from MediaWiki for a legal filename.

Other wikis can now be supported (commit). I've added the Wiktionary, but other could be easily be added in the future.

I finally changed the datatype, it should be better now.

You're right. But as Lingua Libre support way more languages than wikibase do, so it is not possible to set the correct language in all cases. I see three solutions:

• hide with a small JS/CSS snippets the language (as a temporary fix)
• set the correct language if possible, and for unsupported languages use mul (multilingual) (need a bit of development, but it's not very clean in my opinion);
• change the datatype of this property from monolingual text to simple string, as the language is already explicitly defined in an other property (this is the one I prefer, but need to edit manually the DB).

@LucasWerkmeister just pointed out on twitter that items sometimes jump from one line to the next/previous, due to the width difference of the to be read state (it has currently a small border that the other states doesn't have).

Thanks for your feedback!

A first try has been made in this commit, but only one source is yet supported (Wikipedia currently).

A qualifier can now be appended to homograph words to precise their meaning, in the following format: "transcription (qualifier)"
If someone think this is not enough to manage every use-cases, just reopen this task.

Current messages are:

@Aklapper Thanks a lot for your comments and tour help! :)

• if you want to have one project in Wikimedia Phabricator (and e.g. use workboard columns for categorizing subprojects), or want subprojects

Using workboard columns will be easier for us I think (our sub-projects aren't big enough in my opinion).

Huuuu (bis), I've completely forgotten this page... Lingua Libre is not ready (yet!) to welcome developers with little experience of MediaWiki, so I removed it from the page.
Thanks for the reminder :3

Huuu, this is the repository of an old version of Lingua Libre, deprecated since one year. With the project grant linked in the description we moved to the current version, which is a complete rewrite of the old one (and not directly related to WMFr anymore).

That's it. Wikimedians are more used nowadays to report bugs / ask features on phabricator (and they don't need to create a new account), and the board feature here better fits our needs.
Furthermore, in a later point in time when the code base will be more stable, I would like to move the git repository from github to gerrit, to have all inside the Wikimedia ecosystem. Even it's easy to move a repository, moving issues is quite a harder job...

Since everybody seems to agree that the wikitext editor should be the default editor, I've changed the configuration in this way, "not as a perfect solution, but as a way of somewhat improving the situation as soon as possible" as @Whatamidoing-WMF said.