Per this patch to Common.js, the alert is sent to the user on the Record Wizard page. This should be integrated into the Record Wizard's code in the future though.

Renaming files seems to cause transcode issues not only to audio files, but also to video files, see here for instance.
The problem had already been mentioned in 2017.

It just happened to me, while trying to load 200 words from a fr-wiktionary category, with the parameter "exclude words already recorded" on...

@Seb35 do you have news about this? It happened since the re-opening of the website and it is quite a crucial detail
The file seems to be located here: https://github.com/lingua-libre/RecordWizard/blob/master/icons/mic-blue.svg

The request has been made during the wikicamp by @Lepticed7, @VIGNERON and other contributors, and has been improved afterwards by Lepticed7, following some discussions.

In T284137#7169548, @dcausse wrote:

Deployed and available on https://wcqs-beta.wmflabs.org/ via SERVICE <https://lingualibre.org/sparql>, will be available on wdqs after the next deploy (probably next monday).

In T201911#7312071, @Aklapper wrote:

@WikiLucas00: Do you plan to work on fixing this task, as you increased the priority of this task? Asking the Priority field reflects reality and does not cause it.

Sorry, I did not know about the task-priority rules.

As an administrator of Lingua Libre, I am dealing with hundreds of audio files to rename when some users misuse the tool. I tried to deal manually with the transcode reset for approximately 60 files, and this took almost one hour. It would be really nice to not have to do this for every file renamed... Or at least to have a bot dealing with transcodes.
All the best

This problem still occurs, and prevents listening to renamed audio files, on any wiki, if the transcode is not manually reset.

In T286049#7268647, @Pamputt wrote:

where can we find some documentation about the DDF SPARQL?

@Pamputt you can find some info and examples here, on the FR Wiktionary.

Fr-Wiktionary's audio template now supports the level of proficiency of the speaker. See here.

@Pamputt Should I start a discussion in the Wikidémie, or a Prise de décision (or both)?
I coded the new parameter in a draft page here but I'm not sure it would work, could you check please?

I re-open this task because most datasets are still un-updated since 2019 or 2020 (and I am not aware of existing recent discussions about this topic).

@Pamputt I think that a parameter of the template would be ideal for a specific Wiktionary (you are able to change the style of the text by editing the template, and not all the thousands of pages), but using free text will be easier, especially when working with many Wiktionaries (we don't need to change/adapt their own audio-player template everytime). LLBot could add the speaker's level based on the labels of the elements, what do you think about it?
IMO we don't need to specify when the user a native speaker.
I suggest to put the info before the template, so it appears on the same line, e.g.

Hi @Pamputt, I agree and will start to work on this within the coming days. What about a 1 to 5 score as a parameter (similar to Babel, with also a N for native speakers)?

While we need the RW to force users to indicate a place of learning for the future, we also need to search for users who don't have any place of learning for the language(s) they speak, before being able to use the place of learning instead of the place of residence with Lingua Libre. Maybe by adapting this query.

Hi @Xqt: is the change already available (can we use pwb for Lingua Libre)?
Could you tell me what to type for the site = pywikibot.Site('language', 'family') command please?
Thanks @Pamputt for this patch :)

Suggestion of JS snippet, tested and approved by @Poslovitch:

@Seb35 I don't think https://lingualibre.org/sparql is reachable, at least for me.

In T281636#7133573, @Seb35 wrote:

It is fixed permanently for Eihel. If other users have a similar issue, it should be asked to Michael to execute the SQL command. On the longer term, it could be created a frontend to allow admins to do this operation, but this issue is probably exceptional.

@Seb35 @VIGNERON @mickeybarber we might have a similar issue with User:Kunokuno, cf this post.

Great idea, thanks!

In T284645#7145645, @Poslovitch wrote:

As a side question to this : why do we even need to import languages from Wikidata ?

Hello @MPhamWMF, may I ask who you contacted?

If the purpose is to indicate whether selecting this language triggers audio recording or video recording, I think that the P24 property should indeed be added on every language item.
But a more important question is about how we manage languages importation from wikidata, and why we import them individually, please see T284645

Not a high priority for the moment (but a very interesting idea of improvement for the future)

This is possible since version 2 or 2.2 (2020)

Related task : [[T275957]]

Related task : [[T281636]]

@Poslovitch said on Discord (translated from French) :
"With Lyokoï, we discovered a "new" "error message" during the uploading on LiLi. Apparently, it can happen that Commons says "I did not receive the file", while it actually did receive it. So, if you try to upload the file again, well, that won't work because Commons will refuse it, saying that the file is identical to a previously sent file.
So I will have to edit the RW interface to better handle this kind of errors.
In the meantine, the way to see why Commons refuses a file is to open the browser's console, which contains the errors."

@Pamputt: thank you for your screenshots. I agree with you and I close this task. We could re-open it if some images were to be missing.

Hi @Pamputt , I can still see the "Import a language" option at the bottom of the "Actions" menu of every page (which is a bit confusing, and I agree that it would be better to have it in the personal menu). Screenshot on imgur

Another user reported this issue (on Discord) when trying to upload only 1 recording to Commons (he simply couldn't).

I strongly support the initial message.
Having e.g. "Paris" shown as the relevant place linked to a recording when the speaker actually learned the language and lived somewhere else all their life (and just happened to be living in Paris when they filled the "Create a new speaker" form) is, indeed, not acceptable.
In the form, instead of the Place of residence, I suggest we ask for the Place of learning of the language (with maybe the possibility to chose several ones, but I don't know how we could display several places of learning on Wiktionaries)
As said above, the place of learning of a language already exists for some speakers (when one adds a new language, a place of learning can be associated), so we should try to link this new field of the form to the existing data structures used for places of learning.
I suggest to keep the place of residence optional in the field.
We should then update Lingua Libre Bot's code to add the place(s) of learning onto Wiktionaries.

With the project being rebuilt after the fire, I think it is the right moment to implement the Translation Admin status. Indeed, several users are active and serious in their contributions about help and info pages, by translating them or improving the English (source) pages. Changes on source pages requires admins to mark these pages for translation after these contributors are done, while they could (in most cases) have the right to mark this pages for translation themselves.
This right could be implemented in the coming days/weeks if the community agrees, and we would then elect new translationadmins based on their eventual request on the LinguaLibre:Requests for rights page (to be created soon).
Edit: I initiated a communal discussion here 🙂

@Seb35 : Is this issue closed after this edit you made ?

@Yug In my opinion, the issue shouldn't be closed until the actual code is fixed (even if we identified the problem and found a workaround). The piece of code that you added in MediaWiki:Common.css is temporary (waiting for the actual code to be updated), isn't it?

A workaround has been found by @Yug (see the git-hub discussion).
He added the piece of code to the MediaWiki:Common.css page on LiLi as a temporary solution.

In fact, clicking on any link (links from a sub-page to its main page, buttons...) in the headers (in blue) does not work.

In T240552#5948086, @Opsylac wrote:

Faut-il vraiment voter à ce stade ?
Ça me paraît précipité. On n'a même pas discuté des propositions... AMHA ce sont juste des pistes à approfondir.

Ce serait bien aussi de solliciter des avis extérieurs, de gens qui ne connaissent pas forcément le projet (wikimédiens ou non), de personnes qui utilisent la langue des signes... pour savoir ce que leur évoquent ces logos.

Je repense à la proposition bouche+main qui faisait penser aux violences faites aux femmes : quand on a le nez dedans, on ne voit plus ce qui saute aux yeux du premier venu.

In T240552#5929125, @Opsylac wrote:

D'autres variations. Vers la fin, feeling un peu "commons" avec le rouge et bleu wikimédiens

Variations autour des symboles Recording et Play (communs à l'enregistrement audio et vidéo et l'écoute/visionnage de langues parlées ou signées) et des couleurs Wikimédia (présence du nom du projet facultative)

In T231559#5455866, @0x010C wrote:

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.