Chat room/Archives/2019

< LinguaLibre:Chat room


General issues + issues with Odia and Asian writing systems

-- Done, all issue tracked on phabricator or explained below. Ready to archive. Yug (talk) 23:22, 23 December 2018 (UTC)

I loved the current version! Truly admire the changes you all have made over time. I have also done a few recordings in my own language Odia to check for any error. Below are a few:

  1. Tag already recorded items (T212580): When a word has already been recorded and has been uploaded on Commons, does is not make sense to show it as a flag instead of letting any user to upload it directly?
  2. Add custom commons categories (T201135): Also, different languages have different additional categories which Lingua Libre does not let one to add. For instance, I generally add a user category to know how many audio files I have uploaded. For the files recorded using Lingua Libre, I don't see an option to add that optional category.
  3. Remove duplicated words (in same session: explanation below ; across time: T212580): If I am adding a wordlist before recording, is that possible to keep only one word if the same word is used multiple times? This would save some time for the uploader.
  4. Monitor suspect cracking sound in audios (T201136): There is a bit of crackling sound that is heard while monitoring the recorded words. Any particular reason?
  5. Some words fails anyway (T212584): Even though I am correctly pronouncing every word, I see a lot of red-labelled words.
  6. Allow click-play-listen while recording (T212583): While recording, I cannot check how the recording sounds like. I can only choose to re-record after hearing the recorded sound. Otherwise even having that option is of no use.
  7. Remove underline (done): While recording each word is seen as a green button and during the recording the word is underlined. This works well for Latin-based scripts. However for my script, Odia, and even many other Asian languages, this is a problem as we have diacritics and accent marks below the character. It becomes too hard at times to read when underlined. Also, the light green color and a white background is not accessible to people with corrections or color blindness. Maybe black background with white text will create more contrast and make it easier to read.
  8. Last word cannot be re-recorded (explanation below): When you reach the last word of a batch and want to re-record that word, it doesn't allow you to click on the word button and re-record.

Also, requesting to add the Warang Citi (used for Ho language) and Ol Chiki (used for Santali language).

Thank you much again. I would really love to contribute more myself, and involve other community members. --Psubhashish (talk) 07:21, 26 July 2018 (UTC)

First of all, thanks for your feedbacks, that's really helpful. Here are some details about your remarks:
  1. In my opinion, it is interesting to have several records of the same word by different users, the naming convention takes this into account to avoid records to be overridden by another user. But as I'm not sure I understood this point very well, don't hesitate to clarify it if my answer is mistaken.
  2. T201135
  3. If I have correctly understood your point, that's already the case. You can't add duplicate words in the same record batch (if you try to do so, the second one will be dismissed).
  4. It's just a small file-loading issue, it will be fixed soon, see T201136
  5. This is a major issue I'm already aware of. In some cases (~ 1 word out of 100), for some unknown reason, MediaWiki is mistaken in taking WAV files for executable files, so it refuses them...
  6. I'll try to add a way to listen the records while still in the recording studio.
  7. I wasn't aware of that particularities, I'll remove the underline. I'm not so fond of the white text on black, but I'll try to find something more accessible.
  8. Hum, this works well with me. When you have recorded the last word, the record automatically cuts off, did you click on the big red button to enable it again?
I've imported the Ho language, which was missing from Lingua Libre, but the two writing system you've mentionned are part of Unicode and should works, am I wrong?
Best regards — 0x010C ~talk~ 08:37, 3 August 2018 (UTC)
+1 for point 7, the underline is also troublesome for Chinese. Yug (talk) 13:08, 6 August 2018 (UTC)
Hi! Continuing the cleaning effort and tracking of issues, also to stay short and concise, I enhanced the initial post with title and status (phabricator issue). Sorry for that, just cleaner. Yug (talk) 11:33, 24 December 2018 (UTC)
Note: I pointed out to Psubhashish the work on his former feedbacks. See positive discussion on EN. Yug (talk) 13:45, 9 January 2019 (UTC)

Thésaurus (2)

J'ai archivé le coeur de la discussion de Benoit & 0x010C, mais cet autre sujet mérite une section:

"Rien à voir. Je pensais qu'un petit outil de génération de liste depuis un thésaurus fr.wikt ce serait top. Au lieu de choisir une catégorie d'un wikiprojet, on choisirait un thésaurus. Une idée comme ça. --Benoît 21:36, 20 December 2018 (UTC)"

--Yug (talk) 10:41, 24 December 2018 (UTC)

J'ai fait ce modeste outil externe qui génère la liste des mots d'un thésaurus, à coller dans l'interface de LL.
Benoît Prieur (talk) 00:32, 29 January 2019 (UTC)

Erreur de téléversements

Salut, je rencontre un problème assez curieux. Lorsque j'ai fini de m'enregistrer, je choisis de publier sur Commons et là, une partie de mes enregistrements sont publiés et puis ça se met à planter. Après quoi, je ne peux plus en ré-upload pour une certaine période de temps. Que dois-je faire ? Lepticed7 (talk) 21:17, 29 December 2018 (UTC)

Désolé du délai de réponse, j'étais loin de mon ordinateur pour les fêtes.
Est-ce que ça t'es arrivé de nouveau depuis le 29 ? Si oui je vois deux possibilité : soit tu t'es fait déconnecté de Lingua Libre en plein milieu du versement, soit un filtre sur Commons bloque les uploads pour toi pour une raison mystérieuse. Si ça arrive de nouveau, peux-tu essayer d'ouvrir lingualibre dans un nouvel onglet, et vérifier dans cet autre onglet si tu es bien connecté ? Si le problème est là (mais ça devrait plus arriver normalement), une simple reconnexion dans l'onglet d'à côté suffit pour pouvoir ensuire reprendre le versement des enregistrements échoués.
0x010C ~talk~ 15:36, 2 January 2019 (UTC)
Bonjour Lepticed7 et 0x010C. Hier soir nous avons vécu la même situation : à partir d'un certains nombre de versements, une erreur de versement s'affiche à côté des fichier. En fait, je crois que la limitation vient de Commons. Après avoir constaté l'erreur dans Lingua Libre, l'utilisatrice a voulu téléverser un fichier directement dans Commons, et un bandeau indiquait que pour des raisons de sécurité, le versement de fichiers a été bloqué pour quelques temps. Voir cette explication plus complète : [1]
Cordialement, Benoit Rochon (talk) 15:34, 25 January 2019 (UTC)

Menu and naming

See also MediaWiki:Sidebar

Hello the team, from start I've been confused by the name "Record Wizard". A wizard for me is a man doing positive magic in middle age. Recording Studio or Recording Room would seems more expected and readable. Yug (talk) 16:33, 1 January 2019 (UTC)

There is everything fine with word "wizard" in this context, it has more than one meaning. See : "A computer program or script used to simplify complex operations" Wizard for me fits better than Studio or Room in my opinion. KaMan (talk) 16:58, 1 January 2019 (UTC)
It's a technolect, a word known by a minor community, aka "geeks" ^^. Yug (talk) 18:41, 1 January 2019 (UTC)
No, it's not technolect of geeks, it's well established element of user interfaces representing step-by-step process. Just google for "wizard user interface". I don't know why you don't know this term, but it is well known in English when it comes to describing user interfaces in computing. As you can read at the term is used by Microsoft for about 28 years and Microsoft definetly is not for geeks but for everyone. KaMan (talk) 08:21, 2 January 2019 (UTC)
We have to consider organizers and speakers with low English literacy, and we do have them. For Atayal, speaker have 0 English literacy, marginal Chinese literacy, organizer has basic English literacy, full Chinese literacy. Most very local languages ("dialects") are or will be in such case. Let's be honest with ourselves, the UI won't be translate in all these very local languages. They will likely use ur UI in one of the 8 Macro languages (cn, es, en, fr, ru, pt, hi, ar). Our UI language is a barrier.
wizard: 5806th English word by frequency, including all its meaning such 'magician', 'Software UI', see from SUBTLEXus: WORD FREQUENCY AMERICAN ENGLISH. Above rank 5000th it is in the range of vocabulary mastered by nearly fluent learners (C1). I report my feeling that "wizard" is confusing, as it have been foor myself. IMHO our UI should be in Basic English to be readable to all users, same for other 8 macro languages, so to be friendly with basic literacy people in these Macro languages. Yug (talk) 11:15, 2 January 2019 (UTC)
I don't agree with you, UI should follow established UI guidelines. If all other software names step-by-step process by word "wizard" then we should do it as well. From the two words proposed by you "Room" is completly not recognizable in computing as name for wizard-like creator, and "Studio" is reserved for big, complex products like Visual Studio. Our "Record Wizard" is lightweight step-by-step creator and as such should be named like similar processes in similar software. Here are some examples to prove that word "wizard" is used for such step-by-step creators:
KaMan (talk) 13:14, 2 January 2019 (UTC)
On this point I totally agree with KaMan. Using an other word will maybe (or maybe not) help some people, but it will fur sure confuse every english-speaking person. That's why the interface is fully translatable, to let people understand it in their own language.
And by the way, I can add to the list the Upload Wizard on Commons, used daily by thousands of people around the world.
0x010C ~talk~ 15:29, 2 January 2019 (UTC)
[Back from travel]
Your statements may be corrects (many start ups use this word), and mine too:
"wizard: 5806th English word by frequency, including [first meaning] 'magician', [and rarer meaning] 'Software UI', see from SUBTLEXus: WORD FREQUENCY AMERICAN ENGLISH. Above rank 5000th it is in the range of vocabulary mastered by nearly fluent learners (C1)."
Therefore, not Basic English nor inclusive of low English proficiency users.
You are right to list dozens of English-speaking companies using it, still the statement about this word's low readability stay true. Yug (talk) 11:58, 7 January 2019 (UTC)

2019 Prague Wikimedia Hackathon and scholarship (*bourse*)

  • Event: 2019 Prague Wikimedia Hackathon
  • Place: Prague, Czech Republic
  • Date: 17-19 May, 2019
  • Objective: push wikimedia dev projects forward, via coding, networking, documentation.
  • Scholarship : possible ! Please apply before January 8th included. Please send info to potential candidate.
  • Link:

Please spread the word around the world ! Yug (talk) 20:21, 4 January 2019 (UTC)

Word frequencies for prioritizing, UNILEX and licence

Would it make sense to prioritize the data entry, so that users would start recording the most frequent words of a language, and then proceed to the less important words? If you’d like to do this, here’s the word frequencies for 1000+ languages, mostly from crawled corpora. Language codes are IETF BCP47. — Sascha (talk) 08:56, 8 January 2019 (UTC)

This would be indeed useful. To be available on Lingua Libre, we have to create manually (or using bots) lists with these words. I will try to find some time to do it. Pamputt (talk) 12:04, 8 January 2019 (UTC)
Lol. Sascha is in computational lexicology since 1993 ^^ #Boss Yug (talk) 16:14, 8 January 2019 (UTC)
Welcome Sascha, Happy to have your inputs,
We do encourage frequency lists usages (see Help:Why wordlists matter ?). LinguaLibre is still in it's open beta infancy.
Process and quality : We started to add some frequency list (Polish) by hand based on Hermite Dave project (50k list, github, wordpress announcement). Hermite's free data is helpful yet quite raw, namely: polluted by foreign languages. So when available, we use cleaner list from academic research. Ex: Chinese is planed via Subtlex-ch. These raw text lists are then copy-pasted into LL wikipages, so one of these lists is then loaded in the record wizard to provide a list of words for the speaker to read aloud. There is no interactive sorting, it's just loading the list as a text.
Licence : The other issue we have is that half of frequency lists around have weird semi-free licenses not or unclearly compatible with Wikimedia projects. UNILEX's licence is the UNICODE licence.
@LL team : Any idea how we handle data and license asking :
provided that either
(a) this copyright and permission notice appear with all copies of the Data Files or Software, or
(b) this copyright and permission notice appear in associated documentation.
We copy it to the talkpage as well ? --Yug (talk) 16:48, 8 January 2019 (UTC)
Good point about the license. Theoretically I could ask the Unicode Consortium to change the license for Unilex to CC0; but like any relicensing discussion, this would take forever. As the person who started the Unilex project at Unicode, I currently have the impression that Wikidata Lexemes is going to be the better (more scalable, faster progressing, eventually higher quality) approach for collecting lexical data about the world’s languages. So, instead of starting a painful relicensing debate, I think it’ll be easier to simply run corpus crawler to build these word lists from scratch. I’ve written that crawler a while ago to get started with the Unilex project; the Unilex word frequencies were built by running 1000 crawls (one for each language), and then segmenting their plaintext output with ICU word break iterators. I’ve now placed a link to the Corpus Crawler sources on Help:How_to_create_a_frequency_list, in case someone here wants to give it a try. If anything’s broken there, or to support additional languages in the crawler beyond the current 1000, just send a pull request via GitHub. You can also fork the crawler project if you want; the source code is a pretty dull Python script with a regular Apache-2.0 license. — Sascha (talk) 17:02, 14 January 2019 (UTC)

Enable all human languages in bulk?

Would it be possible to support all existing human languages at once? Currently, one needs to file a request for each and every language. It’s not very clear how to do this (which of the admins to contact, and how exactly to contact them?). Also, the LinguaLibre admins surely can make better use of their time than by handling single language requests... For a list of all languages, see the IANA language subtag registry for IETF BCP47. There’s only a few thousand languages, so it might be easy to do this in one single bulk, and then be done. If it helps, I’ll gladly generate a list of (IETF-BCP47-Code, Wikidata-ID) with the mapping, or any other information you’d need for this; feel free to contact me. — Sascha (talk) 09:32, 8 January 2019 (UTC)

+1. I think there is some techical issues for search fields... anyway to go forward ? Yug (talk) 17:07, 8 January 2019 (UTC)
Hi Sascha,
For now on, I only imported languages with an iso639-2 tag, to test Lingua Libre's software with a smaller set of languages for its start (Lingua Libre is still in beta). Importing every languages in the world is planned, but not on the short term, because I still have to check if the database and the software is able to manage smoothly thousend and thousend of languages.
Best regards — 0x010C ~talk~ 18:24, 8 January 2019 (UTC)

Use IETF BCP47 instead of ISO 639?

Currently, LinguaLibre seems to use ISO 639 language codes internally. Consider switching to IETF BCP47; all modern computing standards such as HTML, XML or PDF have moved from ISO 639 to IETF BCP47. For example, BCP47 syntax supports regional variants such as Canadian French fr-CA; language variants such as Sursilvan Romansh rm-sursilv; regional subdivisions such as the Berne variant of Swiss German gsw-u-sd-chbe; and other fine-grained distinctions. See this article for an introduction, and the IANA registry of valid subtags for the complete list. Specifically, the proposal would be to add property IETF BCP47 language tag (Q1059900) to LinguaLibre’s copy of the Wikidata schema, and to use that property instead of ISO 639-3 code (Q56217712). — Sascha (talk) 10:40, 8 January 2019 (UTC)

Hi Sascha!
In fact, Lingua Libre uses nor ISO 639-3 nor BCP47 but Wikidata Qids as internal identifier for a language. Currently, and if I remember correctly, ISO639-3 codes are used in two cases:
  • For the name of pages containing lists in the list namespace (in the format [[List:ISO/List name]], with ISO the iso6369-3 code);
  • To forge Wikimedia Commons's category names
Changing the code would affect only those two parts of the process. If we switch from one language tag to an other, we would have to:
  • Add a new property BCP47 locally as you suggested (a bot can import them from Wikidata);
  • Rename all local lists (can be made by hand, we don't have many lists for now on);
  • Rename all existing Wikimedia Commons categories and move all the audio recordings (a bot there is required);
I have personnaly no opinion on this question, but if several person agree that it would be a good move, I'll add it to the development todo-list :).
Best regards — 0x010C ~talk~ 18:19, 8 January 2019 (UTC)
Cool! I wasn’t aware that you’re internally using Wikidata IDs. This is great, because (other than ISO 639-3) it can model arbitrary languages and dialects.
  • Regarding the lists, would it perhaps be an option to key them by Wikidata ID? Then, arbitrary languages/dialects could be queried, and also regional variants such as Australian English. I don’t know how your server is implemented, but perhaps you could map language codes to Wikidata IDs in your frontend server, so it would not even have to be a user-visible change (apart from supporting more languages).
  • Regarding the names of categories on Wikimedia Commons, what would you think of the proposal to use IETF language codes instead of “other”?
Best, — Sascha (talk)
Sascha (talk) 06:14, 11 January 2019 (UTC)

Documenting langtag usages on LL

See Help:Langtags and Wikipedia Language code#Common_schemes

In our Help:Main, we surely could have a page Help:Langtags (Languages codes and LinguaLibre) to expose our current / planned approaches on the matter. Yug (talk) 13:23, 9 January 2019 (UTC)

Help:Langtags (Languages codes and LinguaLibre) have been initiated. So, for now we are based on LL Qid, ok. Then,
  1. Should these local LL pages contain ISO 639-3 and BCP47 properties, or should they go into the Wikidata page ONLY ? Or both.
  2. Audios files could contains all these as metadata tags. Should they ?
  3. If someone could forge a SPARQL query which list all our active languages on LL, with English name, LL-qid, WD-qid, ISO 639-3, BCP47, it could be an helpful conversion table. Yug (talk) 13:50, 9 January 2019 (UTC)
Yug here is you query :
select ?languageLabel ?language ?WD ?isoCode (COUNT(?record) AS ?count)
where {
?record prop:P2 entity:Q2 .
?record prop:P4 ?language .
?language prop:P12 ?WD .
?language prop:P13 ?isoCode .
SERVICE wikibase:label {bd:serviceParam wikibase:language "en" .} 
GROUP BY ?languageLabel ?language ?WD ?isoCode
As far as I can tell, there is no BCP47 property on LL and I added the number of records in these languages. And I don't know how to share a direct link to the query on ). Cheers, VIGNERON (talk) 09:47, 11 January 2019 (UTC)
I created T213530 to ask for implementing a direct link to a query. Pamputt (talk) 10:23, 11 January 2019 (UTC)

Support variants of Romansh

-- Done -- can be closed Sascha (talk) 20:31, 11 January 2019 (UTC)

Would it be possible to add support for the various variants of the Romansh language?

In the IETF BCP47 language subtag registry, rm-rumgr is the language code for Rumantsch Grischun; rm-surmiran for Rumantsch Surmiran; rm-sutsilv for Rumantsch Sutsilvan; rm-sursilv for Rumantsch Sursilvan; rm-vallader for Rumantsch Vallader; rm-puter for Rumantsch Puter.

In Wikidata, rm-rumgr is Q688873; rm-surmiran is Q690216; rm-sutsilv is Q688272; rm-sursilv is Q688348; rm-vallader is Q690226; rm-puter is Q688309.

In Wikimedia commons, the category tags are subtags of Category:Romansh_pronunciation but they are not very organized; I’ll gladly create new categories if needed.

I’m currently uploading a couple thousand Sursilvan pronunciations, such as “acceptar ezatgei”. It would be great to use LinguaLibre for recording additional variants of the Romansh language, and for recording the missing Sursilvan words. Your toolchain is so much nicer than my bot, so I’d love to switch over. :-)

See also Phabricator ticket T210293 for a related request to support them for monolingual text in Wikidata, which isn’t really related to LinguaLibre but might be interesting as context.

Sascha (talk) 20:18, 9 January 2019 (UTC)

@Sascha it's done!
Note that the Wikidata Qid is enough, we have a script that extract automatically every other needed informations from Wikidata :).
Best regards — 0x010C ~talk~ 09:26, 10 January 2019 (UTC)
For easy access:
So from this live import of pointers~examples I understand how we are rolling : most properties are in wikidata only ;) (It answer my question 1. in section above)
Thanks to 0x010C ! Yug (talk) 12:57, 10 January 2019 (UTC)
Thank you! — Sascha (talk) 14:59, 10 January 2019 (UTC)


Error creating thumbnail: File missing
Audio screenshot

I’ve tried to add support for the Chakma language by adding My Chakma contact (Bivuti Chakma, was able to record Chakma pronunciations, but he reports that the final step (uploading the files to Wikimedia servers) has failed. Probably it’s my fault; I should have asked you instead of trying to do this myself... Apologies for the nuisance, and thanks for your help. — Sascha (talk) 14:52, 10 January 2019 (UTC)

Hi I am Bivuti Chakma from Bangladesh. I am working on my language to implement in technology over the globe.
In you site I have recorded some audio, it's not publish accurately, why?
In this regard I include screenshot of audio.
Thanks, Bivuti
It is not clear to me now, but it seems that creating language "by hand" does not work. So I imported Help:Add_a_new_language should be updated. Bivuti, could you try again on few words and copy here any error message you get. Pamputt (talk) 06:42, 11 January 2019 (UTC)

Thanks Pamputt

When I try to audio recording. The site shows me like this screenshot:

Error creating thumbnail: File missing
Unable to connect
Hi Bivuti!
Thanks for your participation.
I've fixed the language-import thing, which was causing the "Unable to contact the server" error.
Concerning the publishing issue: this question may be odd, but did you actually clicked on the big blue "Publish on Wikimedia Commons" button?
Best regards — 0x010C ~talk~ 04:41, 12 January 2019 (UTC

Hi Yes I have clicked on Publish on Wikimedia Commons" button. After clicking on the button it shows publish failed, try again.


Compress audio?

Should LinguaLibre upload its pronunciations in FLAC format instead of uncompressed Wave files? FLAC is a lossless compression, so it would save space (and bandwidth for users) without losing quality. The only downside is that LinguaLibre’s server would use a bit more CPU, but that’s probably a very minor issue since it’s only needed once per file. To convert to FLAC in maximal compression, you can use something `ffmpeg -i input.wav -compression_level 12 output.flac`. Wikimedia Commons automatically transcodes FLAC to Vorbis and to MP3; see example for an uploaded FLAC file. Just a thought. — Sascha (talk) 15:09, 10 January 2019 (UTC)

Sascha, could you open a Phabricator ticket to track this proposal? Pamputt (talk) 06:50, 11 January 2019 (UTC)
Sure, filed T213534. — Sascha (talk) 11:11, 11 January 2019 (UTC)

Category “Lingua Libre pronunciation-other”

In this test, LinguaLibre has assigned a Commons category Lingua Libre pronunciation-other. Instead of “other”, could it use the IETF language tag (if present in Wikidata)? To get it, retrieve property P305 from the Wikidata record for the language. And perhaps fall back to the Wikidata ID for languages that don’t have an IETF code. Then, the recordings from unrelated languages wouldn’t get conflated. — Sascha (talk) 15:17, 10 January 2019 (UTC)

Indeed, this point has to improved on Lingua Libre. See T208641 on Phabricator. About IETF codes, the problem is they do not cover all the languages/dialects spoken on earth. So the problem remains for languages that do not have IETF code. Pamputt (talk) 06:47, 11 January 2019 (UTC)
Thanks for the pointer; I’ve added a comment to T208641. — Sascha (talk) 11:03, 11 January 2019 (UTC)

Normalize loudness

Should LinguaLibre normalize the loudness of recordings to EBU R 128, so that pronunciations are perceived equally loud irrespective of user microphones? ffmpeg can do this, either if you call it directly (rather painful), or via the ffmpeg-normalize wrapper script. It’s also possible to embed metadata with measured loudness, which some (but not all) players recognize; but in the context of LinguaLibre, it might be best to normalize loudness on the server and resample the signal accordingly. — Sascha (talk) 16:53, 10 January 2019 (UTC)

I would like this normalization for my usages as well, language learning.
Note @Sascha : relevant normalize loudness, denoising , fading-in-and-out cleanups commands to document in Help:Main#Download,_clean,_web_use > Help:SoX (to rename?). Denoise, fading not used serverside so far. 0x010C coded the recorder js and can give specifics. I'am of the opinion that such clean up scripts would sooner (server side) or later (after dataset download) come handy. Yug (talk) 18:33, 10 January 2019 (UTC)
Google:EBU R128 Loudness Normalisation ffmpeg > Audio Loudness Normalization With FFmpeg, Answer: How can I normalize audio using ffmpeg?. Yug (talk) 18:38, 10 January 2019 (UTC)
If normalization was done before uploading to Wikimedia Commons, all Wikipedia users would benefit (eg. when someone clicks on pronunciation icon on Wikipedia, they’d hear the recording in uniform loudness, denoised, etc.). If normalization is done in utility scripts called by end users, the set of people who benefit from this will be much smaller. The trade-off is that the recordings wouldn’t get preserved in their original form, but that’s probably not much an issue for LinguaLibre? — Sascha (talk) 06:24, 11 January 2019 (UTC)
Sascha, could you open a Phabricator ticket to track this proposal? Pamputt (talk) 06:49, 11 January 2019 (UTC)
Sure, filed T213535. — Sascha (talk) 11:17, 11 January 2019 (UTC)
Phabricator starts to have a load of server side developments to do. Not sure volunteers and opensource model will be productive enough. Maybe should we ask for a funding for 2 months dev work. In France it's about 6~8k€. Any lead ? Wikimedia france ? Grants ? Yug (talk) 16:00, 11 January 2019 (UTC)

Request for Comment: Moving from ISO 639-3 language codes to IETF BCP47

Hi Lingua Libre users,

Sascha suggested several times that Lingua Libre should switch from ISO 639-3 language codes to IETF BCP47 language tags. If we do that, it will be a major change in the Lingua Libre code-base. I will summarize here the different usages, pros & cons of such a switch.

Please share your opinion on this bellow!

Thank you all for your participation. — 0x010C ~talk~ 16:59, 12 January 2019 (UTC)


Lingua Libre uses Wikidata Qids as internal identifier of a language. So the proposed change will not affect the core of the Record Wizard. Currently, ISO639-3 codes are used in four cases:

  • For the name of pages containing lists in the list namespace (in the format [[List:ISO/List name]], with ISO the iso6369-3 code);
  • In the name of the datasets archives;
  • In the description of the local item of each audio recording;
  • To forge Wikimedia Commons's category names;
  • To forge each file name that is uploaded on Wikimedia Commons;
Technical considerations

If we switch from one language tag to an other, to be consistent and use the new language tag everywhere, we would have to:

  1. Create a new property BCP47, and add it to every language items localy, for the Record Wizard to be able to use them (a bot can import them from Wikidata);
  2. Rename all local word lists (can be made by hand, we don't have many lists for now on);
  3. Make a quick adaptation in the script that generates the datasets;
  4. Rename all existing Wikimedia Commons categories and move all the audio recordings (a bot there is required);
  5. Update the description of the item of every audio recording in our database (a bot can do it);
  6. Change the way the Record Wizard manages the recording of duplicate words in two different recording sessions: it currently check if a file has already the forged name on Wikimedia Commons, but as the format of the name would change, we won't be able to rely on it anymore.
  • BCP47 is widely used in computing standards;
  • It has codes for way more languages and dialects;
  • It will solve the categorization issue we have currently on Wikimedia Commons (see T208641);
  • We will have a language code to display for way more languages and dialects (we only show the Wikidata Qid in file names for small languages curently, which is not very user-friendly, e.g. File:LL-Q36759-Assassas77-歡喜.wav);
  • Allow to have word lists working as expected for small languages / dialects;
  • Some Wiktionaries (like the French Wiktionary) use this standard to refer to a language in their templates; this is also the case of Wikibase (and so Wikidata) for the language of labels and description.
  • As we cannot rename 60.000+ files on Wikimedia Commons, two different file format will have to coexist (but this is not an issue if you use the SPARQL endpoint to extract the metadatas);
  • As of today, only 3003 languages have their IETF language tag filled on Wikidata (we have currently 8028 languages with an ISO 639-3 code listed);
  • Once the changes made to the Record Wizard and the migration scripts ready to run, we would have to turn off the Record Wizard for one or several days, while the different bots are running to avoid unsynchronized items and conflicts.

0x010C ~talk~ 16:59, 12 January 2019 (UTC)


  1. Support: This will be a hard change but if it has to be done, it's better to do it now rather than in several years. — 0x010C ~talk~ 16:59, 12 January 2019 (UTC)
  2. Contre : French wiktionnary don't use IETF code. Sorry I continue in french : L'IETF fait n'importe quoi avec les langues régionales, c'est pire que ISO 639-3. Nous n'utilisons pas les code IETF, jamais à aucun moment. Soit on prend le code ISO, ce qui marche pour 5000 langues environ, soit on prend le nom de la langue en français, ou en anglais si absent. Aujourd'hui, les contributeurs du Wiktionnaire tendent à s'affranchir de plus en plus des codes et de passer sur les noms de langues en tant que clés primaires. La seule organisation qui fassent l'unanimité sur les langues parce que gérée uniquement par des linguistes, c'est Glottolog, à la limite, on peut se caler dessus, ce sont les plus neutres. Lyokoï (talk) 17:46, 12 January 2019 (UTC)
  3. Oppose (weakly) IETF looks to assign a code to more languages than ISO 639-3 codes. Yet, it does not solve all the issue because I guess it is possible to find language/dialect that do not have either ISO 639-3 or IETF code. In such case, all the issues we have with ISO 639-3 remain the same. If we have to switch to another code system, I has to solve some issues, not only to postpone them. From now, the only code that is flexible and can desribe all language/dialect is the Wikidata code but there are probably other issues if we decide to use them. But since I do not precisely IETF code, I may be wrong so that I do not want to oppose strongly. Pamputt (talk) 19:37, 12 January 2019 (UTC)
  4. Oppose per Pamputt: if it not covers all the dialects then we still have the same problem. Also I don't feel comfortable with two systems in filenames in Commons. I have lots of homonims in Polish and I afraid I would have two files for the same pronounciation from Lingua Libre for one transcription. That would be nightmare for bot operators adding audio files to wiktionaries. KaMan (talk) 09:00, 13 January 2019 (UTC)
  5. Support: There’s a couple misunderstandings here. IETF BCP47 is actually not yet another random codelist that would be different from ISO codes. Rather, BCP47 is a standardized system (and very widely used, eg. in HTML, XML and HTTP) that combinines subtags from other standards. For languages, subtags are taken from ISO 639; for countries, from ISO 3166-1; for provinces/states, from ISO 3166-2; etc. Also, you can add custom information into BCP47 tags without breaking the syntax; this could be used for embedding Wikidata IDs. Here’s a few examples: `en` for English (from ISO 639-1); `haw` for Hawaiian (from ISO 639-3, because Hawaiian has no two-letter code in ISO 639-1); `fr-CA` for Canadian French (language + country); `pt-AO` for Angolan Portuguese; `es-419` for Latin American Spanish (419 is the United Nations M.49 code for Latin America). There is a registry for standardized variants, for example the BCP47 code `rm-sursilv` stands for the Sursilvan variant of Romansh. When a language does not fit into the scheme, you can always append (short) pieces of “private” data after `-x-`. For example, you could encode Verlan (which doesn’t have an ISO language code) as an IETF BCP47 language tag `mis-x-Q1429662` or so. Admittedly, the Wikipedia article about BCP47 is not very helpful at the moment, and the standard itself is very technical. — Sascha (talk) 20:10, 13 January 2019 (UTC)
    As I said, I do not know a lot about IETF BCP47 so I may be wrong. Yet, from the examples you give, you say that the language code comes from ISO 639, so actually if a language do not have ISO 639 code, then BCP47 will not have either. The only advantage I see, compared to ISO 639, is it can represent dialect and regional language (Canada French for example). Youwrite that if a language do not have ISO 639 code, then we can use something like `mis-x-Q1429662`. I do not see what is the advantage compared to simply use Wikidata ID (Q1429662 instead of mis-x-Q1429662). Pamputt (talk) 22:21, 13 January 2019 (UTC)
    In names of dataset archives, names of uploaded pronunciation files, and in the other places where Lingua Libre currently uses ISO 639-3 codes, a BCP 47 tag would be easier to understand than just the Wikidata ID alone. For example, an IETF BCP 47 tag nan-x-Q36759 would identify Teochew as a variant of Southern Min (ISO 639-3: nan) while still pointing to Wikidata Q36759 for the exact identification. — Sascha (talk) 07:03, 14 January 2019 (UTC)
  6. Support: I already have problems due to the impossibility to distinct variants in occitan. For instance, if a gascon occitan want to record words from a predefinite list (because he has no idea of which words to record), he can't search for a list in its variant. He will click randomly on lists names, until he got one in his variant (which can takes long and cause him to give up).
    Second, on Commons, it will be easier for people who doesn't know Wikidata (for instance a teacher who wants to download words in a variety to have his pupils listening them) to get the variety of the word, directly in the results of the search page (with the filenames).
    Third, for the compatibility with developpers programs. At Lo Congrès, we work with RFC5646 (we needed a way to indicate variants). If we make a program which queries Lingua Libre, we need to add a query via Wikidata to get the variety code compatible with our programs. It slows the page and make the work longer.
    I work every day on a language with variants, and for the sort of work I (and others) do, it would be a real improvement. So maybe IETF is theoretically problematic for his language classement, but ISO 639-3 is pragmatically problematic. As a developer, I prefer a usable system that doesn't fit exactly the reality than a system teoretically right that can't be used without a lot of difficulties. — Unuaiga (talk) 16:21, 14 January 2019 (UTC)
  7. Support (for human friendly filenames): I was slow to answer because it's indeed a tricky issue. For all recordings, the value of their langtags −Qids, ISO639-3, BCP47−, exist or can be created. Qids are always new creations assigned when creating the language on LL's wiki, whereas ISO639-3 and BCP47 can exist OR be extended. Each langtag family can covers +5000 languages and do the job we need them for up to 2025~ 2030, with custom extensions when required easier for Qid (still normal creation) and BCP47 (custom extension). Then, the equivalences between these 3 or more langtags can be found by wikimedia editors or outsiders via the Qid or Wikidata pages and few clicks. Afterwhat each langtag and its value can find its way back into the filename via some replacement script. So for me these Qids, ISO639-3, BCP47 langtags are technically equivalents : they each can do the work and be quite interchangeable.
    The question is on HUMAN USAGES. Three groups of humans will manages these files and filenames : 1) LL speakers, organizers and editors ; 2) wikimedia users ; 3) outsiders like android app developers and non-recording linguists. Who is more important ? To who do we want to make access, readability and work easier ? What is their spontaneous knowledge ?
    • The current way: opaque Qid-based filename online, post-download processing to make them readable. We have filename with unreadable Qids, with the actual human-friendly value on LinguaLibre Qid's page. So for us LL editors and maintainers, if we find out our language definition is obsolete, we just update the LL Qid's page, and new people coming there for reference will see the corrected values. For end users on wikimedia cannot directly recognize the language. After files or datasets download, batch renaming commands documented on LL can help end users to renames files as they wish.
    • Datasets and filenames should be human-readable pre-downnload. If so, then the ISO 639-3-based IETF BCP-47 can cover 99% of our easy usages, and BCP-47 has native flexibility to create code for the 1% weird cases. Wikimedia users and outside-wikimedia users will appreciate. If we make mistakes, the vitality of open data spread wrongly name files and will get us troubles.
    • We will need better LinguaLibre-Commons maintenance bots and more bots masters, so we don't always rely on 0x010C, who thereby become our bottleneck. We also need way to massively rename or remove files from Commons.
    • I personally think we have to ease readability to outsiders, app developers and linguists who won't find their way through LL documentations. Also, I'am supporting a move toward human-friendly filenames, from LL website down to wikimedia sites and post-download outsiders' desktops computers. Yug (talk) 21:18, 14 January 2019 (UTC) -note: I have a cold so my English seems worse than usual, my apologize.
Approach For LL editors Wikimedia editors Outsiders
Custom Qid codes,
created as needed,
(LinguaLibre Qids)
Correcting language scope/definition : easy, only change value of fields IETF BCP-47.
Existing files with this Qid, wherever they are, implicitly follow the corrected value.
Opaque filenames, not editable because by convention.
Readable value to find on LinguaLibre.
Commons page can have a def and links.
Opaque filenames.
Value on LinguaLibre's Qid page
Post-download: commands to rename batch of files, documented in Help:Main.
Existing codes,
(ex:ISO 639-3-based IETF BCP-47)
Correcting language scope/definition : Hard, only new recording affected.
Existing files with this code will each require correction.
Readable filenames, no need to rename. Readable filenames.
Ready to go.

Tricky example

Let's take a concrete example, what would be the code for the Gudjal language, a Pama-Nyungan language spoken in Australia? This language has neither ISO 639 code nor BCP47 code. It has a Glottolog, AUSTLANG and identifiers. So if we decide to switch to BCP47, what would be the advantage compared to the existing one (ISO 639) because there is no code in both systems? We simply delay the discussion on the problem of languages or dialects without code. Pamputt (talk) 12:20, 15 January 2019 (UTC)

Since Gudjal is a dialect/variant of Warrungu whose BCP47 code is wrg, the BCP47 code for Gudjal would be wrg-x-Q60610865. To find the prefix for arbitrary languages in Wikidata, it looks like we’ll have to clean up Wikidata a bit. For example, currently there’s no statement in Wikidata linking Verlan to French; we’d need that to come up with the code fr-x-Q1429662 for Verlan. — Sascha (talk) 19:23, 15 January 2019 (UTC)
Indeed, wrong example because some work say this "language" is actually a dialect of the Warrungu language.
So let us consider the Bunwurrung language, another Pama-Nyungan language spoken in Australia. This one does not seem to be (yet?) a dialect of another language. So, what would be its BCP47 code? The same for Bwenelang language, a Austronesian language spoken in Vanuatu. Pamputt (talk) 20:11, 15 January 2019 (UTC)
In the short term, their codes would be mis-x-Q4997965 and mis-x-Q56261010. In the long term, it would be good to assign ISO 639-3 codes to these languages. This is actually quite easy (if there’s references about the language). See FAQ, or this example registration request. Requests are reviewed once per year. All changes to ISO 639-3 also go into the registry for BCP 47. — Sascha (talk) 11:23, 16 January 2019 (UTC)
Thanks for the examples. In my opinion, "mis-x-Q4997965" is more cryptic than only "Q4997965". If a language has a ISO 639-3 code, then the BCP47 code is indeed easier to understand than a Qid. So, as I already said, the advantage is to make clearer the code for the dialects but it does not solve all the problems (such as these two languages. Since such code change will not be done every month, I would prefer to have a better solution (more universal) before breaking/changing everything. Pamputt (talk) 17:42, 16 January 2019 (UTC)
I find mis-x-Q4997965 less crypting : as soon as you know the naming scheme you can assume mis-x-* is a rare language. If 98% of our languages get clearer with BCP47, and 2% are such as mis-x-Q4997965, it's a net improvement of 98%, let's go for it. Let's not force to the throat of our end users a 15th new standard. Yug (talk) 17:04, 26 January 2019 (UTC)

Encoding Wikidata IDs into BCP47

By the way, in a BCP47 language tag such as wrg-x-Q60610865, anyone can stuff anything after -x- which is flexible but not ideal for an identification scheme. I’m now preparing a formal proposal for encoding Wikidata IDs into BCP47 language tags. BCP47 already draws subtags from many other registries such as ISO 639, ISO 3166, UN M.49 and others; so why not treating Wikidata as yet another “registration authority”. If the proposal gets accepted, the official syntax would be something different than -x-. Just for your information; I’ve no idea if the proposal gets accepted, and it usually takes a long time to make changes. — Sascha (talk) 12:20, 16 January 2019 (UTC)

Thanks Sascha ! It would be awesome. Yug (talk) 18:24, 13 February 2019 (UTC)

Ne pas proposer les termes pour lesquels on a déjà téléversé un enregistrement


Tout est dans le titre : si je reprends les termes d’une liste déjà partiellement enregistrée, LinguaLibre me propose d’en réenregistrer tout les membres, ce qui ne me semble guère pertinent. Il devrait plutôt ne proposer que des termes pour lesquels je n’ai encore rien enregistré.

Cordialement. Penegal (talk) 17:36, 20 January 2019 (UTC)

Hello Penegal ! This feature has been requested before. We have a phabricator task on it (T212580),defining the problem and storing on the LinguaLibre developers' dashboard. Previous discussion have concluded that this feature isn't easy to provide. We call for volunteer developer.s with required skills to jump in and develop a script providing this service.
Which word lists do you work with ? You could compare the lists before work, using comm (comm -13 recorded.txt nextlist.txt). An alternative is to progress not via thematic lists or extracts from texts as of now on FRA, but with method, more specifically by recording words from the most frequent to the lesser ones. We currently don't have large frequency list for FRA. If this would satisfy your needs, please message me. Yug (talk) 22:12, 20 January 2019 (UTC)
I could use that, but how would you extract the list of already recorded items? Starting from my contributions list doesn't seem very scriptable. Is there an API or something that could give me a parseable output? Penegal (talk) 17:31, 21 January 2019 (UTC)
I definitively need a list of your previous recordings to use it as reference for comparison via comm. I guessed you used lists from Special:PrefixIndex/List:Fra and could tell me which ones you previously used ? Now I pray :D Yug (talk) 18:24, 21 January 2019 (UTC)
Oh, all good. I have something I can work with. Yug (talk) 18:29, 21 January 2019 (UTC)
After 1040x2 deletions, it's clean : List:Fra/Penegal-temp. Give me one evening to come with your next wordlists. Yug (talk) 18:39, 21 January 2019 (UTC)
You mean you'll have to update this list for me each time? I hope not; I can't ask you to be my bot, it will be a pain in the ass to you. Penegal (talk) 18:18, 22 January 2019 (UTC)
I use's fr corpus of 106.8M (3.5Gb) sentences to create a reliable oral french frequency list. I will subtract from it the list of your recorded words, so the next words you do are new. I'am on it right now, working smooth, having fun, ready soon. Few more hours of work needed. The shell commands i use will be shared so other members can do it as well for most of the 60+ other languages. Yug (talk) 20:51, 22 January 2019 (UTC)
Umh, based on OpenSubtitle's corpus[1] and my current shell commands, there is what I get : Special:PrefixIndex/List:Fra/subtlex-for-user-Penegal, from 0001 to 8000th for now. More if you need. It's a solid frequency list. Yet I'am not satisfied : there is quite some noise.
  1. Noise: Lot of characters names, a bunch of basic English words. I review and cleaned up the 6000 to 8000th list: out of 2000 items, I had to edit 206 modifications (10%) and make 82 deletions (4%) (diff, open view-source: and search for "diff-deletedline" and "diff-addedline").
  2. Script improvements: as we review anc correct these files, I will keep track of the edits we do and integrate them to my script to generate better list, with or without English words and with or without names. Another direction would be to compare this list to Lexique3's items, since they already made this verification.
  3. Immediate priority: I will review and edit-clean up these files by hand to 1) remove *pure* English words, 2) recapitalize names. It takes about 20 by page. Help welcome (adopt a file ici). I'am also and must continue to improve and document these commands. Yug (talk) 23:05, 26 January 2019 (UTC)
Wow, you lost me. What are you trying to do? Penegal (talk) 09:15, 28 January 2019 (UTC)
Hahahaha. I try to create a good, open license, systematic frequency list so FRA speakers may record French words following an efficient recording path. Efficiency being measured as lexical coverage of spoken French corpus compared to recording effort. It makes more sense to record frequently occurring words first. Then go down the road. (But there is some noise in my frequency list, see 26 January 2019's message XD)
Then, on this list, I subtracted your previous 1000+ records, so the lists and words in Special:PrefixIndex/List:Fra/subtlex-for-user-Penegal are all new to you AND statistically the most frequent on spoken French corpus from
It makes sense from a computational linguistic point of view, I'am not sure I satisfy your former request tho. But it was fun to do ^^ Yug (talk) 10:49, 28 January 2019 (UTC)

Requête Wikidata pour la création d'une liste de mots

Bonjour !

Quand j'essaie de créer une liste de mots à partir d'une requête Wikidata, j'obtiens toujours la même erreur. Voilà l'URL que j'utilise.

L'erreur indiquée est "Result must contain both "id" and "label" field.". Est-ce que j'ai raté quelque chose ? :) Exilexi (talk) 17:16, 29 January 2019 (UTC)

Salut Exilexi, est-ce que tu peux essayer avec cette requête ? Pamputt (talk) 20:48, 29 January 2019 (UTC)
Bonjour Pamputt, ça me donne la même erreur. --Exilexi (talk) 13:23, 5 February 2019 (UTC)
En effet, je passe mon tour, car je n'ai pas plus d'idée. Je pense qu'il faudra attendre qu'0x010C passe ici pour te répondre. Pamputt (talk) 18:42, 5 February 2019 (UTC)
Salut Exilexi,
Cette requête va fonctionner : [2].
En fait, l'analyseur de résultats est assez simpliste pour le moment, il faut forcément que le Qid (ou Lid) de ton item soit dans une colonne nommé ?id et que le label associé dans une colonne nommé ?label. Quand j'en aurais le temps, je pourrais améliorer cela, mais ce n'est malheureusement pas encore pour tout de suite... :/
Bons enregistrements ! — 0x010C ~talk~ 23:32, 19 February 2019 (UTC)

Mauvais code langue

Bonjour, Un de mes locuteur n'a pas choisi le bon code langue lors de l'enregistrement de la liste Oci/cosina , est-il possible de corriger les noms de fichiers (Ex : LL-Q150 (oci)-Ives (Guilhelma)-adobar.wav au lieu de LL-Q150 (fra)-Ives (Guilhelma)-adobar.wav ?

Salut Guilhelma,
J'ai commencé il y a quelques semaines à développer un script pour effectuer des corrections à grande échelle. En attendant, j'ai listé les enregistrements en question sur LinguaLibre:Misleading items en mémo, comme ça dès que j'aurais fini hop je corrigerais tout d'un coup :).
Cordialement — 0x010C ~talk~ 08:40, 9 February 2019 (UTC)
Merci Guilhelma

For your information (langtag)

Google Speech documents its languages support using ... Yug (talk) 18:21, 13 February 2019 (UTC)



Je serais très intéressé de savoir comment vous avez paramétré le lecteur TimedMediaHandler.

En effet, je souhaiterais que les utilisateurs puissent rapidement différencier les sons en rapport avec le mot lui-même de sa prononciation, si possible avec un lecteur plus compact pour la prononciation. Surtout que nous n'avons pas besoin de la barre de navigation dans le fichier pour des fichiers autant courts. Vous trouverez un exemple de mon "problème" ici.

Merci ! DSwissK (talk) 21:42, 20 February 2019 (UTC)

Bonjour DSwissK,
Les lecteurs audio présent dans le RecordWizard et sur les pages de la sonothèque ont été créé spécialement pour Lingua Libre, et n'ont rien à voir avec l'extension TimedMediaHandler. C'est le bout de javascript suivant qui en est responsable :
function playButton( audioUrl ) {
	var button = new OO.ui.ButtonWidget( {
		framed: false,
		icon: 'play',
		title: 'play'
	} );
	button.on( 'click', function() {
		var audio = new Audio( audioUrl );;
	} );

	return button.$element;
Lorsqu'un le RecordWizard ou la sonothèque récupère l'url d'un media audio, ils le passent à cette fonction qui en retour renvoie un element JQuery qu'il suffit d'insérer à l'endroit désiré dans la page.
Cordialement — 0x010C ~talk~ 21:59, 20 February 2019 (UTC)
Super, merci beaucoup. Je vais donc essayer ça. DSwissK (talk) 12:00, 21 February 2019 (UTC)

Lien direct vers fichier .ogg


Je remarque que les fichiers envoyés au format WAV sont automatiquement transcodés en MP3 et OGG.

Est-il dès lors possible d'utiliser directement ces fichiers avec un lien direct ?

Pour le fichier , j'ai tenté de faire lire, avec html5player, mais sans succès (en plus de l'URL compliquée...)

DSwissK (talk) 12:53, 22 February 2019 (UTC)

Salut DSwissk,
Tu as du faire une erreur autre part, car cela fonctionne très bien. Le player Kaltura, qui est le lecteur multimédia utilisé sur les wikis Wikimedia, tape d'ailleurs sur cette même version transcodé en OGG ;). Tu peux le tester tout simplement avec une balise audio <audio src="" controls> (par contre, oui, l'url est longue et reloue...).
Cordialement — 0x010C ~talk~ 13:53, 22 February 2019 (UTC)
Merci pour ta réponse rapide, 0x010C. J'ai effectivement réussi en insérant le code suivant dans le modèle "{{#tag:html5media|{{urlencode:{{{prononciation|}}}|WIKI}}/{{urlencode:{{{prononciation|}}}|WIKI}}.ogg}}"
Le problème : chaque fichier à un répertoire de transcodage différent. C'est donc impossible de faire un lien direct depuis un modèle vers le bon endroit, n'est-ce pas ?
Merci et belle fin de journée. DSwissK (talk) 15:28, 22 February 2019 (UTC)
Je ne connais pas ce player html5media, mais la façon la plus propre ça serait plutôt que ce soit lui qui forger la bonne url (comme le fait Kaltura sur les wikis Wikimedia), si tu tiens à avoir de l'ogg et non du wav. Sinon, t'as toujours la solution de calculer à la volée le nom du répertoire dans lequel se trouve le fichier. C'est en fait les deux premiers caractères du hash md5 du nom du fichier (cf doc), que tu peux facilement calculer avec la fonction mw.hash.hashValue( 'md5', nomDuFichier ) en lua si l'extension Scribunto est installé.
Cordialement — 0x010C ~talk~ 22:44, 22 February 2019 (UTC)
Merci de ta réponse. Je n'ai pas installé l'extension Scribunto (et je me sens bien incapable de coder en Lua) mais il me semble que TimedMediaHandler (qui est, lui, installé sur le wiki) utilise Kaltura. Saurais-tu comment lui demander de forger la bonne URL (ou alors le forcer à s'afficher en mode "audio") ? DSwissK (talk) 13:48, 23 February 2019 (UTC)
Si ça peut servir à quelqu'un (comment forcer l'affichage "moderne") :
Il faut ajouter "$wgTmhWebPlayer = $wmgTmhWebPlayer;" dans LocalSettings.php DSwissK (talk) 16:49, 23 February 2019 (UTC)

Some bugs

Lingua Libre is awesome! Thank you for developing it! I found some issues:

  • After setting my Name in the preferences to "Michael Schönitzer" (with ö) all uploads fail:
  • The record more files on the "Publish" page does not work
  • When deleting a recording in the "Publish"-page there is no possibility to record it again it.
  • Words I already recorded show up again when using one of the generators.

Hope those bugs can be fixed! I use Firefox 65 on Linux. -- MichaelSchoenitzer (talk) 23:34, 28 February 2019 (UTC)

  • Concerning the name that uses UTF8 characters, I opened T218373
    Concerning the not working "record more files", I opened a bug report about it: T218371
    Concerning the second point (When deleting a recording in the "Publish"-page there is no possibility to record it again), I do not think there is any bug report on it. Feel free to open one.
    Concerning recording again words you have already recorded, see T212580
    Thanks for reporting these bugs. Pamputt (talk) 23:20, 14 March 2019 (UTC)

Hackathon Bordeaux, May 2019

More info LinguaLibre:Events

Hi everyone, Edouard and myself will gather in early may to lead a one day, 10am-6pm hackathon in Bordeaux city, France. Please follow the dedicated page and add your name if your are interested to join in and keep informed. Best regards ! Yug (talk) 11:45, 28 March 2019 (UTC)

New languages (Bikol languages is a macro language)

Hi! I am an editor in Wikipedia and I would like to contribute in these languages but I could find the following:

  • Buhi’non Bikol [ubl] -> see Q115106
  • Central Bikol [bcl] -> see Q115107
  • Libon Bikol [lbl] -> see Q115108
  • Miraya Bikol [rbl] -> see Q115109
  • Northern Catanduanes Bikol [cts] -> see Q115110
  • Rinconada Bikol [bto] -> see Q115111
  • Southern Catanduanes Bikol [bln] -> see Q115112
  • West Albay Bikol [fbl] -> see Q115113

Please add these languages. Thanks!

Filipinayzd (talk) 06:16, 29 March 2019 (UTC)

Dear Filipinayzd, welcome on Lingua Libre. I created all the languages you asked for. You can now start to record some words in these languages. Good luck. Pamputt (talk) 06:49, 29 March 2019 (UTC)

Stats History

Hi there, As we get closer to the 100,000 audios milestone I would like to see the quantitative evolution of LinguaLibre these past 8 months. Are we speeding up or slowing down ? This kind of things. Does anyone know how we could get the number of audio we had the 1st day of each month since August 2018 ? Ideally by editing a bit the first query of the stats page.
So far I hand-collected this :

Date Items Speakers Languages Comment
2018.08 ? ~10 5 Alpha release; Mainly tests.
2018.12 ? ? ? Beta release.
2019.04.01 93173 128 46

Yug (talk) 08:57, 1 April 2019 (UTC)

I've just added a new section to the Stats page :)
Best regards — 0x010C ~talk~ 01:14, 2 April 2019 (UTC)
Thank you 0x010C :D Pamputt (talk) 04:35, 2 April 2019 (UTC)
Thank 0x010C ! :D Yug (talk) 14:11, 2 April 2019 (UTC)
Would it be possible to add a sum of the records over the months (and not only for a given month), so that we can see the evolution of the number of records as a function of the time? Pamputt (talk) 19:11, 2 April 2019 (UTC)
You want cumulative rather than just by monthly actions. Yug (talk) 10:03, 8 April 2019 (UTC)
Yes. I guess this is possible using the SUM function available in SPARQL but all my tests failed. Pamputt (talk) 13:08, 8 April 2019 (UTC)

Euh... les stats sont figées depuis quelques jours, y'a un soucis avec la base ? Lyokoï (talk) 22:50, 18 April 2019 (UTC)

A tool to add our files quickly to wikidata

I would like a way to push my contributions quickly on wikidata (so they are out there helping people asap).

Currently, I

  • Look on my contributions in wikicommons
  • find one that is unused
  • search for the word I created in wikidata
  • if it doesn't have a pronunciation
  • click on the item
  • choose add
  • type "audio pronunciation"
  • paste in my filename
  • add "language of work or name" as "British English"

Now this to me sounds like work a bot should be doing, or at least be a one-click action from our contribution page, is there any work being done to make something like this happen? Back ache (talk) 00:36, 21 April 2019 (UTC)

Hi Back ache, Lingua Libre Bot automatically adds the new pronunciation on both items and lexemes on Wikidata. It does every night. Pamputt (talk) 14:42, 21 April 2019 (UTC)
Hi Pamputt it doesn't seem to be working for my entries, I am having to do them manually :-( it'd be great if it were to do them automatically as I find adding them repetitive. Back ache (talk) 19:55, 21 April 2019 (UTC)


Hello every one, 0x010C ask to say that the Endpoint is out due to a script crash, linguaLibreBot is out too. He is actually in moutains and we need to wait 3 days before the repairing. Thanks for waiting. Lyokoï (talk) 22:45, 23 April 2019 (UTC)

Sorry for the delay. I've just restarted the script that update Lingua Libre's Sparql endpoint, it should take approximately 2h to catch up. Lingua Libre Bot, as it uses the endpoint to get the new audio recordings, will also catch up and everything should be back around 06h (UTC). Best regards — 0x010C ~talk~ 01:01, 29 April 2019 (UTC)

Bonjour à Tous, j'ai reçu un message de 0x010C indiquant que le endpoint n'est plus alimenté car le script a dû crasher. LinguaLIbreBot est tombé aussi. Actuellement 0x010C est en montagne et ne récupèrera une connexion valable que dans 3 jours. Nous vous demandons de patientez jusque là pour qu'un rétablissement soit fait. Merci d'avance et désolé. Lyokoï (talk) 22:45, 23 April 2019 (UTC)

Désolé pour le temps de réaction. Je viens de relancer le script qui alimente l'endpoint Sparql de Lingua Libre, il devrait mettre environ 2h à ratraper le retard des jours passés. Une fois fait, Lingua Libre Bot (qui utilise l'endpoint comme source et qui donc ne pouvait fonctionner) repassera sur tous les enregistrements manquants. D'ici 06h (UTC) tout devrait être rentré dans l'ordre. Cordialement — 0x010C ~talk~ 01:01, 29 April 2019 (UTC)
Merci pour la réparation. C'est reparti pour un tour. Pamputt (talk) 05:41, 29 April 2019 (UTC)
Merciiii ! :D Lyokoï (talk) 08:50, 29 April 2019 (UTC)

Add language category's

When uploading files, could it use the metadata to also add categories so as to help organise mediawiki for example, taking the metadata that says I am "British English" and adding "Category:British English pronunciation" to each of the files I upload? Back ache (talk) 22:08, 27 April 2019 (UTC)

The easiest way I see to achieve that is to say that you speak "British English" and not simply "English". I created Q123270 so you can use it. Pamputt (talk) 21:50, 28 April 2019 (UTC)

100 000

A little less than a year after the launch of the beta version, we have done it. The goal of 100,000 audio recordings has been reached with cybernétique of the user Lepticed7.

Well done, and congratulations to all! — 0x010C ~talk~ 05:10, 2 May 2019 (UTC)

I took the opportunity to generate a bonus stat: 74% of files are used on at least one page of a Wikimedia project and 99,000 pages include at least one audio recording of Lingua Libre. — 0x010C ~talk~ 05:33, 2 May 2019 (UTC)

Un peu moins d'un an après le lancement de la béta, nous y sommes. La barre des 100 000 enregistrements vient d'être franchi ce matin avec cybernétique de Lepticed7.

Félicitation, et bravo à tous ! — 0x010C ~talk~ 05:10, 2 May 2019 (UTC)

J'en ai profité pour générer une stat bonus : 74% des fichiers sont utilisés sur au moins une page d'un projet Wikimedia et 99 000 pages tous wikis confondus incluent au moins un enregistrement de Lingua Libre. — 0x010C ~talk~ 05:33, 2 May 2019 (UTC)

J'ai écrit un court message à diffuser : Lingualibre:Chat room/Annonce 100 000 si vous pouvez passer derrière pour le traduire ce sera top ! Lyokoï (talk) 13:48, 8 May 2019 (UTC)

Update lists of suggested words

Are the suggested lists are updated somehow? I recorded some word twice before a recognized that there is no marker or warning for words that have a soundfile already. What can I do? --Sebastian Wallroth (talk) 09:47, 4 May 2019 (UTC)

This is a well-known request. That is why I created this task on Phabricator. Pamputt (talk) 18:08, 5 May 2019 (UTC)
Thank you, Pamputt. --Sebastian Wallroth (talk) 17:59, 9 May 2019 (UTC)

Feature request: Adding DEFAULTSORT

First: Lingua Libre is a great tool! Many thanks to the developers!

I have a proposal:

When a new audio-file is exported to Commons, it was great if this new file had a line with a DEFAULTSORT with the same content as the already existant parameter "transcription".

gruß, fcm. --Frank C. Müller (talk) 14:29, 8 May 2019 (UTC)

I created T222816 to track this request. Pamputt (talk) 16:42, 8 May 2019 (UTC)
Thankyou! gruß, fcm. --Frank C. Müller (talk) 18:51, 8 May 2019 (UTC)
Hi Frank C. Müller and Pamputt,
In fact, the Template:Lingua Libre record on Commons (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. If you take a category like Category:Lingua Libre pronunciation-fra, you can see that it is already sorted by alphabetical order of the transcription.
Best regards, — 0x010C ~talk~ 07:43, 9 May 2019 (UTC)
Ok, but if I take another Commons-category, e.g. Sounds by Frank C. Müller, then all the LL-files without a "DEFAULTSORT" are listed under "LL". gruß, fcm. --Frank C. Müller (talk) 09:56, 9 May 2019 (UTC)
Ok, I got your point. I've just edited the template on Commons so now all the audio recordings have a defaultsort :).
Best regards — 0x010C ~talk~ 02:39, 13 May 2019 (UTC)
Dear 0x010C, thanks a lot for your change! But e.g. in Commons:File:LL-Q188 (deu)-Frank C. Müller--ales.wav and Commons:File:LL-Q188 (deu)-Frank C. Müller-Abduktor.wav I can see no DEFAULTSORT and in Commons:Category:Sounds by Frank C. Müller they are still not sorted adequately under "-a" and "A" but under "LL". gruß, fcm. --Frank C. Müller (talk) 12:27, 13 May 2019 (UTC)
The defautsort will not be displayed in the wikicode of the file as it is included through the template. When you have checked just several hour after my edit you faced a common problem on wikis: it takes a lot of time for the server to refresh all pages after a heavily used templates like the Template:Lingua Libre record is edited. If you check it now, you can see that its working fine :).
Best regards — 0x010C ~talk~ 01:55, 16 May 2019 (UTC)
Hi 0x010C, thanks for your explanations!
LL-Q188 (deu)-Frank C. Müller--ab.wav now is adequately sorted and in the Page information the Default sort key is indicated correctly as "-ab".
But right now e.g. LL-Q188 (deu)-Frank C. Müller--isier.wav and LL-Q188 (deu)-Frank C. Müller-Abdeckmaterial.wav both are sorted under "LL" and their Default sort key in the Page information is still wrong.
So I shall wait another day and then have a look once more.
gruß, fcm. --Frank C. Müller (talk) 08:24, 16 May 2019 (UTC)
If you want to force Commons to update the cache, you can do a null edit (maybe a bot exists that can do that on all files?); otherwise we just have to wait... — 0x010C ~talk~ 09:00, 16 May 2019 (UTC)
So, now I got them all. Thanks a lot! gruß, fcm. --Frank C. Müller (talk) 10:00, 17 May 2019 (UTC)

Technical news - May 2019

Hi all,

This is the first edition of the technical news, a newsletter posted here on the Chat Room each month starting today to keep you informed of what's going on on the tech side.

Recent changes
The new Exclude words you have already recorded option

A new version of the RecordWizard has just been released. Among new translations and a bunch of small code rewriting, a new major feature has appeared. It is now possible to exclude automatically all words you have already recorded when you prepare a list of words for a recording session. To do so, a new option has appeared inside each word list generator to enable (by default) or disable the feature, see screenshot. A button bellow the list do the same job for words typed manually. It definitely was the number 1 requested feature, you can test it right now and give me some feedbacks!

Future changes
  • A module that allows Lingua Libre Bot to add the audio recordings made with Lingua Libre to the English Wiktionary is at it's final step of development and will be tested in the coming weeks.
  • Thanks to a financial support from Wikimedia France, a new video recording studio will soon appear to record sign languages!
  • A new gadget will allow administrator to mass edit items of audio recordings (to fix a mistake for example).

Best regards — 0x010C ~talk~ 10:41, 16 May 2019 (UTC)

Thank you 0x010C for these nice new features, especially the one that allows not to record again a word that we have already recorded. About the "module to connect Lingua Libre Bot to the English Wiktionary", I do not understand what does it mean. What is the goal of this module? Pamputt (talk) 13:23, 16 May 2019 (UTC)
It will allow Lingua Libre Bot to add the audio recordings made with Lingua Libre on the English Wiktionary, as it does on the French or Occitan one. ;). — 0x010C ~talk~ 20:56, 16 May 2019 (UTC)
Thank you 0x010C. I love the feature to avoid duplicate recordings! --Sebastian Wallroth (talk) 06:42, 18 May 2019 (UTC)
I really love the new option, it works great! It made things a lot easier. Would it be possible to allow to also exclude all words spoken by any editor? So that it's easier to work in a team on a project with the aim to have spoken all words in some area collectively. -- MichaelSchoenitzer (talk) 14:42, 17 June 2019 (UTC)
@MichaelSchoenitzer, could you give an example of which words do you want do exclude and for which reason? It would make easier to understand your request because I do not understand it for now. Pamputt (talk) 16:42, 17 June 2019 (UTC)
If I understood correctly, he wants a new option to be able to exclude all words that have already been recorded, in complement of the actual option that allow a user to exclude all words that he/she has already recorded.
For example, I've recorded the word kayak in French, so with the current excluding setting this word wont show up anymore to me, but it can show up to you as you haven't recorded it.
As I see it, it could help increase the number of distinct words recorded in languages with a small number of speakers, by avoiding concentrating the small number of volunteers on words already recorded.
This is totally doable (and pretty easy now), the only concern I have is about the UI part. I have no idea on how to add this option without the interface becoming too messy... If someone has a good idea, a mookup would help me a lot to create this feature.
0x010C ~talk~ 02:29, 18 June 2019 (UTC)
Thanks for the exaplanation. It makes sense. About the UI, it is indeed tricky. What about adding a "Lingua Libre" tab in Special:Preferences that allow to set all the main preferences (this one and others)? Pamputt (talk) 05:52, 18 June 2019 (UTC)

Actualités technique - mai 2019

Bonjour à tous,

Ceci est la première édition des actualités technique de Lingua Libre, une infolettre mensuelle pour vous tenir informé régulièrement sur ce qu'il se passe dans l'arrière boutique. Bonne lecture.

Nouveautés du moi
La nouvelle option Exclure les mots que vous avez déjà enregistré en image

Une nouvelle version du RecordWizard vient juste d'être publié. Outre de nouvelles traductions et une séries de petites réécriture de code (pour préparer des changements futurs), une fonctionnalité majeure à été introduite. C'est la possibilité d'exclure automatiquement tous les mots que vous avez déjà enregistrés par le passé lorsque vous préparer une liste de mots. Pour ce faire, une nouvelle option est apparue dans chaque générateur de liste pour activer ou désactiver cette fonctionnalité, cf. la capture d'écran ci-contre. Un bouton sous la liste permet de faire de même pour les mots ajoutés manuellement.
C'était la fonctionnalité la plus demandée depuis le lancement de Lingua Libre, vous pouvez à présent la tester et me partager vos retours à son sujet !

Changements à venir
  • un module permettant à Lingua Libre Bot d'ajouter les enregistrements audio produits ici sur le Wiktionnaire anglophone est en phase finale de développement et sera testé dans les semaines à venir.
  • Grace au soutient de Wikimédia France, un nouveau studio d'enregistrement vidéo va bientôt apparaître dans le RecordWizard pour enregistrer des langues des signes !
  • un nouveau gadget permettra bientôt aux administrateur d'éditer les items d'enregistrement audio en masse (pour corriger des erreurs par exemple).

Cordialement — 0x010C ~talk~ 00:44, 17 May 2019 (UTC)

Merci pour ces actus ! C'est une superbe fonctionnalité que de pouvoir exclure les mots déjà enregistrés. Pressé de voir ce que ça donnera pour la LDS ! GrandCelinien (talk) 07:32, 31 May 2019 (UTC)

Feature request: ask to reuse existing identical audio if available (part 2)

Lingua Libre bot seems to work like that: getting all forms of a lexeme, delete duplicate entries, add recorded file to one of the duplicates.

Example: There is a recording for the German word "Bildung": File:LL-Q188 (deu)-Sebastian Wallroth-Bildung.wav. Lingua Libre bot added the file to the lexeme form L11818-F4. But it would also fit to L11818-F1, L11818-F2, L11818-F3.

I would suggest not to delete the duplicates, but to add the recorded file to all of them.

P. S. I tried a workaround by adding the files to the other lexeme forms with Quick Statements, but Quick Statements cannot access lexeme forms yet. --Sebastian Wallroth (talk) 06:20, 24 May 2019 (UTC)

I created T224312 to track this request. Pamputt (talk) 19:44, 24 May 2019 (UTC)

Feature request: add language qualifier to lexeme form pronunciation audio statement

Let Lingua Libre bot in Wikidata add the qualifier P407 (language of work or name) to the statement P443 (pronunciation audio).

Example: In the lexeme form box of there is a question mark sign indicating a problem. The popup message claims: "This pronunciation audio statement is missing a qualifier language of work or name."

--Sebastian Wallroth (talk) 06:20, 24 May 2019 (UTC)

I created T224312 to track this request (I opened only one ticket for both feature requests). Pamputt (talk) 19:46, 24 May 2019 (UTC)

Import Shtooka audios ?

fr:Shtooka, le parent direct de LinguaLibre, dispose d'une collection de 120,000+ audios (Farm-Fresh file extension zip.png Farm-Fresh file extension zip.png). Is there a plan to import these 120,000+ audios into LinguaLibre ? Since it is a non trivial migration (cf meta data), I'am considering to apply for a microfi or grants in order to pay a dev to do it. Do we have anyone with experience with this task ? Yug (talk) 08:05, 6 June 2019 (UTC)

Elle a déjà été importée sur commons, non ? Lyokoï (talk) 21:26, 8 June 2019 (UTC)
Tout ? Au même format que LL ? En tout cas on ne les voit pas dans, c'est domage. Yug (talk) 17:44, 10 June 2019 (UTC)
Il nous faut ces jeux de données dans le datasets, et manipulable par les bots LinguaLibre. Yug (talk) 17:54, 10 June 2019 (UTC)
Sûrement pas ! Mais les fichiers sons sont là depuis longtemps par contre il me semble. Il faut faire matcher les deux jeux de données. Template:Clin Lyokoï (talk) 19:42, 11 June 2019 (UTC)
Bonsoir Yug,
Attends deux secondes, tu brûle quelques étapes là. Avant de faire un micro-fi ou de recruter quelqu'un, il y a des questions à se poser, genre : "Est-ce pertinent ?" ; "Est-ce souhaitable ?" "Est-ce que les serveurs supporteront un quasi doublement en peu de temps ?" ; "Est-ce vraiment prioritaire actuellement ?" ; "Quitte à chercher des sous, est-ce qu'ils ne seraient pas mieux utilisés à développer autre chose ?" ; "Est-ce pertinent ?".
Tu dis, je cite, qu'« Il nous faut ces jeux de données ». Ok mais, tu pourrais développer un peu ? Car en vrai, je ne vois personnellement aucune raison à l'heure actuelle (si ce n'est d’accroître artificiellement le compteurs d'enregistrements et plomber pour de bon l'endpoint Sparql) de faire un tel import. Les fichiers sont déjà sur Commons pour la plupart, importé là-bas et utilisé sur de nombreux projets depuis des années.
Cordialement — 0x010C ~talk~ 12:06, 12 June 2019 (UTC)

Actualités technique - juin 2019

(an English translation will come soon)

Bonjour à tous,

Nouveautés du mois
  • Le gros changement de ce début juin, c'est le support des langues des signes sur Lingua Libre. Dorénavant, celles-ci peuvent être sélectionné comme n'importe quel autre langue, auquel cas vous accéderez au nouveau studio d'enregistrement vidéo. Celui-ci fonctionne sensiblement de la même façon que l'enregistreur audio, au détail près que la découpe des enregistrements se fait au bout d'une durée prédéfini.
Attention, une limitation technique issue de MediaWiki limite actuellement la prévisualisation aux vidéos de 4s ou moins, ceci sera changé dans le futur (cf T97539).
  • L'interface de la dernière étape du RecordWizard a changé pour éviter de devoir faire défiller longuement la page. C'est un premier pas qui sera suivi d'autres modifications dans le futur. Si vous avez des propositions, n'hésitez pas à me les faire parvenir !
  • Une nouvelle option permet de limiter le nombre de mots récupérés en utilisant le générateur Catéggories Wikimédia. Cela permet de travailler avec certaines catégories du Wiktionnaire qui peuvent contenir plusieurs dizaines de milliers d'entrées.
  • Un bug faisait que Lingua Libre Bot supprimait des caractères de retour à la ligne dans certains rare cas sur le Wiktionnaire francophone. Cela a été fixé.
  • Les enregistrements sur Commons sont dorénavent catégorisé par utilisateur, en plus de la catégorisation par langue. Vous pouvez toutes les retrouver dans la catégorie mère Category:Lingua Libre pronunciation by user.
Changements à venir
  • Il sera bientôt possible de modifier les paramètres internes du studio d'enregistrement audio, par exemple la durée d'un silence entre deux mots.
  • Les changements annoncé le mois passé ont pris du retard mais sont toujours en développement.
Merci beaucoup 0x010C pour tous ces nouveaux développements, en particulier pour la possibilité d'ajouter des mots en langue des signes. Ca fait vraiment plaisir à voir. Pamputt (talk) 04:59, 22 June 2019 (UTC)
Génial ! Merci pour cette évolution. Je communique très rapidement sur la possibilité d'enregistrer des langues des signes !! Lyokoï (talk) 23:04, 23 June 2019 (UTC)

Replace “Place of residence” with something more relevant, or don't automatically import on Wiktionary?

Hi! Great project!

A little suggestion: I’m French, and after 25+ years of living in France, I happen to have been living in Copenhagen for the past two years, which is completely irrelevant concerning the variant of the French language I use. Still, when LinguaLibre asked me for my “Place of residence”, I said “Denmark”. I recorded one word as a test a few days ago. Now the recording has been automatically added to its corresponding Wiktionary entry with the label “Royaume du Danemark (Danemark)”, which is quite absurd and is giving a confusing information to the readers of Wiktionary. I would suggest removing “Place of residence”, or replacing it with “Home country” or “Place where you mainly learned your language” or something similar (that said, none of these two fit everyone’s life story either).

In addition, I wonder if the automatic upload to Wiktionary should happen. What if I record some words in English? (my browser is set in English so I was automatically going to record words in English before I realised it didn’t make much sense). I’m not sure entries from ”English for France” are that relevant on Wiktionary. Maybe it should only automatically upload clips from the countries that have this particular language as an official language (from Wikidata information)? On top of that, my recording was not that great (I have to set up my microphone better or remove the noise in post-prod), so I wonder if uploading many mediocre clips without listening to them “manually” first might diminish the quality of the dictionary.

Nclm (talk) 14:36, 18 June 2019 (UTC)

Salut Nclm. I opened a Phabricator ticket in order to track your request. To me, it makes sense that "Place of residence" is probably not the best wording. So it is needed to think about that. Pamputt (talk) 22:26, 13 July 2019 (UTC)

TypeError: Cannot read property 'indexOf' of undefined

Bonjour, Lorsque je souhaite importer une liste de mot depuis une catégorie du Wiktionnaire, ce message d'erreur d'affiche et m'empêche d'importer la liste.

Savez-vous à quoi c'est dû et comment le régler ?

Hello, When I want to import a list of words from a category of the French Wiktionnary, this error message pops and prevents me from to import the list.

Do you know where it comes from, and how to work it out ?

WikiLucas00 (talk) 22:42, 2 July 2019 (UTC)

Bonjour WikiLucas00, je n'arrive pas à reproduire. Quelle catégorie essaies-tu d'importer ? Quel est ton navigateur ainsi que sa version ? Pamputt (talk) 06:12, 3 July 2019 (UTC)



Dans le Wikimag publié demain, la section “Coups de Coeurs” présente le projet. Vous pouvez y apporter les modifications que vous souhaitez.

Cordialement, AirSThib (talk), le 16:34, 7 July 2019 (UTC).

Enquête annuelle de Wikimédia France

Bonjour à toutes et tous,

Chaque année, Wikimédia France souhaite donner la parole à l'ensemble de la communauté sur les grandes orientations choisies par l'association. De même, si vous avez des idées, des projets contributifs et que vous souhaitez ou avez besoin du soutien de Wikimédia France, n'hésitez pas à remplir ce formulaire, nous vous recontacterons.

L'ensemble de l'équipe salariée est à votre disposition,

Je vous souhaite un bel été,

Rémy Gerbet WMFr (talk) 14:17, 17 July 2019 (UTC)

Some issues with the Record Wizard

Upon recently recording a few words, I noticed some issues with the Record Wizard:

  1. The "Enregistrer plus de mots" (fr) button works erratically. It would sometimes bring you back to the expected step of the Record Wizard, yet most of the time it'll do nothing.
  2. Upon verifying the records that were just made (right before smashing that "upload" button :D), going to the previous step would make the "mic" button ineffective. In order to re-record the same word, you need to go back to the word list and re-add the word.

These issues make the UX quite frustrating, although they are not preventing any further work with the website.

--Poslovitch (talk) 19:05, 20 July 2019 (UTC)

Bonjour Poslovitch, concernant le premier probleme, il y a deja un ticket ouvert sur Phabricator. Si 0x010C passe dans le coin, est ce que tu pourrais nous dire ce qu'on pourrait faire (debogueur firefox ou autre ?) pour tenter d'apporter de sinformations utiles a la resolution de ce probleme ?
Pour le deuxieme soucis, je ne crois pas qu'il y ait encore de ticket pour suivre ce soucis. J'ouvrirai un ticket un peu plus tard (si tu ne le fais pas avant). Pamputt (talk) 08:49, 21 July 2019 (UTC)
A propos du probleme de micro, j'ai cree T229299. Pamputt (talk) 02:40, 30 July 2019 (UTC)
Salut Poslovitch, salut Pamputt,
Merci à vous deux pour ces retours. Il n'y a pas besoin d'autres infos, celles déjà présentes permettent de reproduire facilement ces deux bugs. Cependant (vous l'aurez sans doutes déjà remarqué), je ne suis pas des plus disponible ces temps-ci à cause de mon travail saisonnier, un fix de ma part n'est pas pour demain :/.
Cordialement — 0x010C ~talk~ 06:01, 29 July 2019 (UTC)

Proposition d'ajout de fonctionnalité


L'option "Exclure les mots que vous avez déjà enregistrés" est très utile et permet d'économiser beaucoup de temps et d'énergie.

Serait-il possible d'inclure une option similaire dans la prochaine version, qui permettrait d'exclure les mots déjà enregistrés par un autre contributeur LinguaLibre ?

Il est évidemment intéressant d'avoir pour un même mot plusieurs enregistrements de locuteurs différents (et c'est même le but final). Cependant, on peut aussi se pencher sur la possibilité de prioriser dans un premier temps les entrées n'ayant encore aucun enregistrement, ce qui permettrait de fournir au moins un enregistrement audio sur un maximum d'entrées du Wiktionnaire, et d'éviter aux contributeurs de se concentrer sur les mêmes mots que les autres. Cela donnerait la possibilité de travailler "en équipe" plutôt que chacun dans son coin ; si l'on décide par exemple de s'attaquer à la "Catégorie:Verbes en français" (34 399 pages), on peut fournir à tous les termes un enregistrement très rapidement en évitant d'enregistrer les mêmes entrées que les autres contributeurs. Une fois qu'une majorité d'entrées possède au moins un enregistrement, on peut continuer à enregistrer des mots sans regarder s'ils ont déjà été prononcés.

Évidemment, il ne s'agirait que d'une option pour les contributeurs intéressés par ce mode de travail, et personne ne serait obligé de l'utiliser.

Qu'en pensez-vous ? prévenez-moi si je ne suis pas clair!

WikiLucas00 (talk) 15:28, 13 August 2019 (UTC)

Salut WikiLucas00, je viens d'ouvrir un ticket sur Phabricator pour garder une trace de ta proposition. Pamputt (talk) 14:38, 29 August 2019 (UTC)
Salut Pamputt, merci beaucoup ! WikiLucas00 (talk) 23:20, 11 September 2019 (UTC)

Nouveau point de contact pour Lingua Libre

[English below]

Bonjour à tous,

Je m'appelle Emma, je suis étudiante et depuis août 2019, je travaille à Wikimédia France sur le projet Lingua Libre dans le cadre d'un service civique.

Si vous avez des questions, suggestions, projets à proposer, ou si souhaitez simplement discuter de Lingua Libre, votre expérience avec l'outil et comment vous souhaiteriez qu'il évolue à l'avenir, n'hésitez surtout pas à m'écrire. Mon adresse mail est emma[point]vadillo[at]wikimedia[point]fr

Pour ceux qui seront présents à la WikiConvention francophone la semaine prochaine, ce sera certainement une première occasion pour nous rencontrer et peut-être organiser une réunion de discussion ou un atelier d'enregistrement au cours des périodes de contribution libre.

A bientôt!

Hello everyone,

My name is Emma, I am a student and work for Wikimedia France since August 2019 on the Lingua Libre project.

If you have questions, ideas, projects to suggest, or wish simply to discuss about Lingua Libre, your experience with the tool and how you would like it to evolve in the future, do not hesitate to write to me on emma[point]vadillo[at]wikimedia[point]fr


eavqwiki (eavqwiki)

Bonjour Emma, tout d'abord bienvenue à Wikimedia France et dans le monde merveilleux de Lingua Libre. Est ce que tu peux nous en dire davantage sur ton rôle dans le cadre de cette mission ; quel sera ton travail au jour le jour ? Au plaisir de te croiser à la wikiconvention :) Pamputt (talk) 14:34, 29 August 2019 (UTC)
[English below]
Bonjour Pamputt, déjà merci à toi et Mahuton pour la présentation de Lingua Libre à la wikiconvention francophone :)
Et merci à tout le monde présent ici pour faire grandir ce projet!
Je suis en charge de la stratégie de Lingua Libre. Wikimédia France réfléchit à la direction que peut prendre Lingua Libre dans l'objectif d'oraliser les projets Wikimedia. Personnellement je suis très attachée à la diversité culturelle et linguistique et je pense que wikimedia peut participer à la préserver dans l'espace numérique à travers Lingua Libre.
Pour cette raison, ça m'aiderait beaucoup si vous remplissiez cette enquête (10 questions) sur votre utilisation de Lingua Libre: merci d'avance!
J'aimerais aussi avoir les retours plus détaillés de celles et ceux d'entre vous qui pourraient me faire part plus longuement de leur expérience avec l'outil afin de le développer et l'améliorer :) Des intéressé(e)(s)?
PS is there a need for English translation?
Hello Pamputt, thank you and Mahuton for the Lingua Libre presentation at the wikiconvention francophone
And thank you to everyone having made this project grow!
I am in charge of the strategy for Lingua Libre. Wikimedia France is reflecting on the role Lingua Libre could play in the attempt to make wikimedia projects oral. Personally I care a great deal about cultural and linguistic diversity and I think that Wikimedia can take part in preserving it on the web through Lingua Libre.
Therefore, it would be very helpful if you would fill in this survey (10 questions) on your use of Lingua Libre: thank you in advance!
I'm also looking to have more detailed feedback from those of you willing to share more at length their experience on Lingua Libre with me in order to improve it :) Anyone interested?
eavqwiki (eavqwiki) 11:30, 27 September 2019 (UTC)
Hi eavqwiki, yes I think you should translate this message into English because we have "a lot" of non-French speaking people contributing to Lingua Libre. Yet, your survey is only in French for now, so I let you see. Pamputt (talk) 12:54, 27 September 2019 (UTC)
[English below] C'est noté j'ai traduit le questionnaire qui est disponible toujours sur le même lien.
Sure, the survey is now translated into English and available on the same link.
eavqwiki (eavqwiki) 12:10, 30 September 2019 (UTC)
Hello, you might post this on the Bistro, on Wikipedia. Maybe it would bring new users ! :) I'm talking about the french one, but you could try on the village pump. Welcome ! GrandCelinien (talk) 08:50, 2 October 2019 (UTC)

Adding sounds to the pronunciation claim in Wikidata

Recently ru-wiktionary was mass-ported to Wikidata Lexemes (nouns only for now). As part of that massive effort, the community established a hopefully better way to store pronunciations in lexemes - pronunciation property (P7243) (~100,000 usages). See talk page for docs, and a great discussion (where Pamputt has raised a number of good points).

Could this tool be adapted to create such pronunciations?

The tool would look for any forms with pronunciation claim, but without a sound file, and offer to record it. Here's a Russian word showing how pronunciation is stored:

Thank you for such an awesome tool! --Yurik (talk) 03:01, 13 October 2019 (UTC)

Hi Yurik. There is already a Phabricator task asking to improve the LinguaLibre code for Wikidata. I only add a link to this post in order to keep track. Anyway, if you have time, you may send a pull request to apply this change; all the code is available on Github. Pamputt (talk) 15:36, 13 October 2019 (UTC)
We can get random words from Wikidata, but it isn't obvious how to upload them.~Is this issue exactly about that? -Theklan (talk) 16:48, 25 October 2019 (UTC)

Vote for a new logo and interface for Lingua Libre

(English below) Bonjour, Vous pouvez voir les propositions de logo et maquettes graphiques pour Lingua Libre ici : T240552 Donnez-nous vos retours et votez pour garder le logo ou adopter la proposition #1, #2 ou #3 ici :

Hello, You can view the proposals for a new logo and interface for Lingua Libre here: T240552 Please give feedback and vote whether you prefer keeping the logo, or adopting the proposal #1, #2 or #3 here: -- eavqwiki (eavqwiki) 10:19, 12 December 2019 (UTC)

(English below) Mise à jour des maquettes : n'hésitez pas à aller refaire un tour sur Phabricator et donner votre avis sur les dernières propositions - surtout le record wizard et le logo !
The proposals were updated : don't hesitate to visit Phabricator once more and give your opinion on the last suggestions - especially the record wizard and the logo!
-- eavqwiki (eavqwiki) 04:03, 30 December 2019 (UTC)

Erreur de langue d'enregistrement


Je viens de m'apercevoir d'une erreur de ma part concernant la langue de mes 1111 derniers enregistrements (en français mais annoncés comme du finnois): [3].

Pouvez-vous m'aider à réparer ça s'il vous plaît ? Merci beaucoup !


I made a mistake which I just noticed, related to the language code of my last 1111 recordings ([4]). They are recorded in French, but I chose a wrong language (Finnish) in the Record Wizard. Can you help me to fix them?

Thank you very much!

WikiLucas (🖋️) 12:02, 21 December 2019 (UTC)

Salut Wikilucas,
Tu peux les lister sur cette page LinguaLibre:Misleading_items, je les corrigerais en masse une fois que j'aurais fini l'outil d'édition en masse (promis il arrivera un jour).
0x010C ~talk~ 23:43, 30 December 2019 (UTC)
Salut 0x010C,
J'ai également parlé du problème sur commons ([5]), on m'a dit de changer le code de langue sur chaque fichier via un gadget (done), et qu'ils changeraient les noms des fichiers problématiques par bot (ça pose quand même un problème pour les enregistrements qui n'étaient pas inédits mais une nouvelle version d'un enregistrement existant).
J'ai plusieurs questions : comment lister les 1111 items sur la page que tu m'as indiquée sans avoir à les entrer un par un ? Y a-t-il un moyen d'extraire en wikitexte mes imports récents ?
Même si les changements sont effectifs sur commons, faudra-t-il aussi changer les infos des fichiers ici ?
Pour mes fichiers problématiques (qui ont été enregistrés en finnois), sera-t-il possible de récupérer l'information relative au français (mon origine lyonnaise) ?
Merci pour ton travail et ton temps, bon réveillon !
WikiLucas (🖋️) 12:30, 31 December 2019 (UTC)