The newly created Wiktionary in Sorani (code ckb) has the same behaviour: Cognate is working on the Sorani Wiktionary but the other Wiktionaries do not see the Wiktionary in Sorani. For example water links to the other Wiktionaries but the French Wiktionary does not list the entry on the Wiktionary in Sorani.

I reverted because one should list only the "main" language code. Aliases are for Wiktionary internal purpose and must not be used by LLbot. If we really want to add them in the Lingua Libre Wikibase, then we should mark these values as deprecated.

So I go ahead and I have created a new property. See an example here. I think we can use "Wikimedia language code" property to avoid creating a new one.

Not using the Lingua Libre wikibase anymore? Why not, but I don't think it's going to happen tomorrow. By the way, are there any public discussions (a Phabricator ticket or something) where you can read about the state of thinking on the subject?
So in the meantime, I think adding a property to the Lingua Libre wikibase is not such a bad idea.

Dans T329568#8613730, @Lepticed7 a écrit :

On the wikidata element of the calabrais, maybe we can add a property like "identifier in Wiktionary", with the value "calabrais centro-méridional" and a qualifier "wiki" with the value "French Wiktionary".

This query gives currently 46 Lingua Libre languages that do not have ISO 639-3 code.

Hmmm, not sure if the Wikidata community will accept such a property that is very specific. I mean I do not know how to write a property proposal because the only need for now is for Lingua Libre Bot.

Dans T329568#8613533, @Lepticed7 a écrit :

Hi. Is it not possible on wikidata, with a specific property?

This is rather important topic because currently minor languages without ISO 639-3 code are not supported by Lingua Libre Bot and thus recordings are not added into Wikimedia projects.

The WAV specification indicates (page 23) in the INFO List Chunk section that metadata can be stored in a WAV file among predefined chunks ("keywords"). The specification says also "New chunks may be defined, but an application should ignore any chunk it doesn't understand". So in principle, we can define our own metadata and add them in the WAV file. Obviously, we need to document the new chunks somewhere. See alo https://www.robotplanet.dk/audio/wav_meta_data/

I have written a bash script that loops over all languages supported in Lingua Libre and request all recordings for each language. Then, Lingua LIbre Bot runs on a given wiki project to add all missing recordings. For languages with a large number of recordings (for example French), I split the resquest year by year.

Actually, Cognate links work on the Gungbe Wiktionary. For example osin on the English Wiktionary proposes a link to the Gungbe Wiktionary. And osin on the Gungbe Wiktionary also proposes links to the other Wiktionary versions.

Dans T321666#8504825, @Pamputt a écrit :

I just discover that there is an issue with Cognate and the newly created Wiktionary projects. Two examples:

• • On the Igbo Wiktionary: the entry agba links to all other Wiktionary version, but the same page on the other Wiktionary versions does not link to the Igbo page (for example, here is the French page that does not contain any link to the Igbo Wiktionary)
• On the Gorontalo Wiktionary: the page taluhu links to all other Wiktionary version, but the same page on the other Wiktionary versions does not link to the Gorontalo page (for example, here is the French page that does not contain any link to the Gorontalo Wiktionary)

I did not check if there is already a Phabricator ticket for this problem (if not I will create one) but it may be related to the problem described in this ticket.

I just discover that there is an issue with Cognate and the newly created Wiktionary projects. Two examples:

Is there any plan for the data engineers to work on that topic?
It is enable for Wikipedia since a while and [https://stats.wikimedia.org/#/fr.wiktionary.org/contributing/active-editors-by-country/normal|map|last-month|(activity-level)~5..99-edits|monthly stille nothing] for the Wiktionary projects.

@Yug could you create anew ticket to ask to implement that in the extension repository and tag it as feature rrequest. Otherwise, I fear it will be forgotten soon.

What I understand is to allow double licence, not to set default licences: CC by sa + CC0. If you want this dual licence to be the default, could you elaborate why it should be the default instead of other licence (CC0 only, CC by-sa only, etc.)?

See the Technical board.

Hello, it is said that the new page is updated automatically.
If so, how are chosen the languages of the Wiktionaries that are displayed at the bottom? For example, if I am not wrong, the Tacawit Wiktionary (shy.wiktionary.org) that has about 3500 entries currently is not listed.

The error message "Error saving translation: You have been blocked from editing." is indeed correct but does not explain at all why one is block from editing. I would expect a clearer message. But if you consider there is no issue and I am alone to complain about it, then no problem.

The French Wiktionary is also intested in such feature also to manage links in translation templates.

I maybe experience the same issue.

Dans T239272#6046005, @0x010C a écrit :

@Pamputt I'm not sure the "linked user" property would be usefull on Commons, imho the LL property P5 "speaker" is more relevant. A property P823 (speaker)" exists on Wikidata, but it only accepts items. Thus, is it relevant to create wikidata items for each speakers?

A new Wikidata property related to Lingua Libre audio files has been created. See https://www.wikidata.org/wiki/Wikidata:Property_proposal/Lingua_Libre_ID : P10369

See also https://github.com/lingua-libre/CommonsDownloadTool/issues/2

I tried to run create_datasets.sh. The problem occurs when the script is at the "Download and package ALL sounds..." step.

I do not know whether the server has already been updated but it seems the new syntax is still not known by MediaWiki. See https://lingualibre.org/index.php?diff=683554 for example. Maybe @Eihel knows a bit more. At https://www.mediawiki.org/wiki/Help:Extension:Translate/Page_translation_administration#Segmentation, it is written that the new syntax is supported since Translate version 2021.04 but on https://lingualibre.org/wiki/Special:Version, I see that Translate version 2020-04-20 is installed.

See also https://lingualibre.org/wiki/LinguaLibre:Chat_room#.5BFeature_Request.5D_Play_next_sound_automatically_while_checking_recordings

See also: https://lingualibre.org/wiki/LinguaLibre:Chat_room#commons%3Acommons%3Astructured_data

There was a bug in LLbot (introduced by myself) and that has been fixed. It should not happen anymore. But let this task opens until we have removed all the pronunciations in doublon.

It appears that CommonsDownloadTool needs to be fixed to solved this issue. If @Poslovitch is not wrong, the problem comes from the fact there are too many files to get from Wikimedia Commons in one time and there is a ratelimit that is currently not supported by CommonsDownloadTool and which prevents the download to success.

@Noe, @WikiLucas00 where can wwe find some documentation about the DDF SPARQL? For example, what are the prefixes and so on? In short, how to write a DDF query?

Because it concerns only the French language, would it be possible to develop a generator gadget instead so that it can be enable only by French contributors?

@Seb35 if this commit this commit is taken into account, do you know why the Vector skin is still available on Lingua Libre?

I opened a pull request concerning frwiktionary.

Dans T276013#7261602, @Eihel a écrit :

I also started a discussion between the place and the country in the "écouter" template, example: Paris (France). So, there would be consequences from LiLi. @Pamputt

Bon, bah je me suis lancé. J'ai ouvert une discussion sur la Wikidémie

I think the Wikidémie is good. If there are a lot of discussions, we will start a Prise de décision, but I think we can avoid it.

Agreeds with all what you propose. Do you want to start a discussion on the French Wiktionary to ask to add such parameters in the écouter template? LLbot should be able to add this information for each Wiktionary that is interested in; I do not see any issue about that.

I have opened a pull request on Github to select and display the place of learning when it exists instead of the place of residence. I let @Poslovitch review it and merge it if ok.

Hi would prefer something in full letter. Currently, we have a code something like

I tried to reproduce the problem. To do so,

Hi @WikiLucas00, let us start to implement that on the French Wiktionary. Could you propose something to de displayed within the "écouter" template?

Created as P9729.

@WikiLucas00, both language and family are "lingualibre", so you can use

site = pywikibot.Site('lingualibre', 'lingualibre')

and yes, it is already available in the master branch.

I proposed a patch at https://gerrit.wikimedia.org/r/c/pywikibot/core/+/703625
I am clearly not an expert of the Pywikibot core so it may be not correct but it works for me.

Dans T215055#7031318, @Pamputt a écrit :

Does someone know how to enable translations in javascript gadget such as Gadget-ExternalTools.js, so that it is possible to translate "This is not an allowed URL... It should link to PetScan or Wikidata Query." and so on?

Dans T215055#6875890, @Pamputt a écrit :

There is also this page (https://lingualibre.org/wiki/Special:Log/remoteupload) where we cannot translate (I did not find where) the sentence "These events track when someone upload a file to the remote wiki using OAuth."

That's said, it would be useful to be able to translate "Remote upload log" as well (like for the other logs)

And also be able to translate the log message such as

2 mars 2021 à 19:41 Pamputt (discussion | contributions | bloquer) has uploaded a file to the remote wiki: File:LL-Q150 (fra)-Pamputt-fuselage.wav

The difference comes from the datatype of the properties: P2 (instance of) has the Item datatype so the Wikibase checks that the value that is entered is an item; P12/P14 have the external identifier datatype. So the a priori check cannot be done. On Wikidata, there is the constain system that allow to check a posteriori that the values are correct (or at least look correct).
I do not know whether we can use the constrain system on the LinguaLibre Wikibase (@VIGNERON ?) but I think we cannot do better because this is how the Wikibase works.

.I don't feel comfortable with a massive import mainly because among all the elements that are languoids, there is a mix between language families, dialects, varieties, etc. And so I wonder about our means to manage all of this. So agree to import list of "official" langages but skeptical about a massive import

Looks to be fixed by this modification.

I have created new screenshots so I think we can close this task because I am not aware about other pages where images are missing.

Oh yes, sorry. I got mixed up with the menus... No real opinion about the best place for the menu. So I close this report.

@Seb35 in the part "I know what I'm doing" (at the bottom), there are still some missing images (not recreated). It is possible to recreate them and close this task. So I would say it depends how difficult it is for you to receover the lost images. If it is too long, I think we should close so that you can concentrate on other tasks.

Indeed, so it is probably related to T269885.

Indeed, it is fixed. I close this task.

This bug is solved in the new version of Lingua Libre (MediaWiki 1.35). @Seb35 I let you close this bug report.

Solved -> https://lingualibre.org/wiki/LinguaLibre:Administrators%27_noticeboard#Recording_bug_and_MediaWiki:Sitenotice_edit

@Eihel, what is the error that appears? I made a change and save it and I did not get any error.