Could you confirm that you talking about https://phetools.toolforge.org/transclusions.html ?

Not exactly what you expect but entities about Wikimedia pages also have other triples like :

• schema:inLanguage (that gives the languages code)
• wikibase:wikiGroup (that gives the names of site).

Reviving this old task.

It just happened to me also (on many lexemes, including L1, L2, L3, L4, L5, L16, L3870, L448884 etc.).
For some context, it appeared on multiple browsers (Firefox, Chrome, Edge) and also when log out.

Still planning to work on that but not in the short-term.

For the record, ping @AndrewTavis_WMDE ;)

Indeed, it works fine now (maybe just a cache problem on my side or something). Closing the task again.

It seems something is incomplete yet. At least the ISO codes don't works on Lexemes lemmas and forms.

It seems that they is a bug on the Wikisources.
At least on the French Wikisource, there is *never* an image displayed, even in the case where there is an image on the page.
See for instance the first result on : https://fr.wikisource.org/w/index.php?search=intitle%3A"Les+Rougon-Macquart"&title=Spécial:Recherche&profile=advanced&fulltext=1&ns0=1 (I tried to give a simple example, there is also different case where the image is inside a template, transcluded or retrieved from Wikidata).

Another comment: how will the Wikidata Query Service (WDQS) handle mul ?

Suscribing JeanFred for inteGraality

I think this is quite important (for discoverability and so on) so I set priority to "medium".

I understand that indeed it could be a bit confusing for someone coming from Wikidata (especially for a federated query between LinguaLibre and Wikidata). Prefixes are chosen totally arbitrarily and can be chosen as we wish, so: what should we choose?

I'll need to double check but it seems that we use the 2.2 for the main site and 2.3 for the dev site (@Poslovitch is dev.lingualibre.fr sill needed ? and/or could it be needed in the future ?).

In T203220#7464167, @VIGNERON wrote:

I'll ask the community on the Scriptorium (the local village pump), but I know that at least some people on fr.ws would be interested.

I'll ask the community on the Scriptorium (the local village pump), but I know that at least some people on fr.ws would be interested.

I found none; please be more explicit

Well, I agree this is « desired » but this is complicated and not only technical.

An important point (I think I wrote it somewhere already but I double here to be sure it's not lost) :

• it's the blue mic when recording an audio
• it's the blue hands when recording a video (for sign language, icon is https://github.com/lingua-libre/RecordWizard/blob/master/icons/hands-blue.svg I think)

Clearly importing *all* languages (lato sensu) from Wikidata doesn't seems to be a good idea. But on the other hand, it would make sense to import some "important" missing languages. Between 600 and 10 000, there is probably a sensible middle-ground.

In T283839#7120490, @Bstorm wrote:

@VIGNERON Openrefine is changing the files to world-readable somehow. I don't know why yet, but it should not be used until this is fixed. Please stop using it. We will remove it from PAWS until this is sorted out.

Side note, @Bouzinac has all but guessed this vulnerability over at https://www.wikidata.org/wiki/Wikidata_talk:Tools/OpenRefine#OpenRefine_now_available_on_PAWS%21, I suggest reaching out to prevent any further public speculation.

To be more specific, the files workspace.json and workspace.old.json both contains in clear the username and password wikidata_credentials":["username", "password"] and now on PAWS these files are public (here is mines https://public.paws.wmcloud.org/1200/ for instance).

I change the task a bit. This kind of tool in called a generator (see Help:Create a new generator on lingualibre).

@Theklan : in the third screen of the RecordWizard, you have a box at the bottom right called ExternalTools.
This tool allows to add a SPARQL query, for instance a query on Lexemes.
It's not 100% direct but I think it's good enough, isn't it ?

Yes, thanks a lot @Poslovitch !

ping @Ladsgroup ?

Yes, the challenge itself is only 2 hours (it's already long enough, I can attest it :P).
I think it's important to prepare some page, explaning the principle of the challenge and a list of people who want to participate.

It looks great

• there was a small typo, I forgot a comma, it is dezhañ, dezhi and not dezhañdezhi
• some inflected forms are quite rare but that is to be expected

+1, I volunteer and I'll be very glad to help reproduce this fun activity.

The history says it was added by @0x010C (https://lingualibre.org/index.php?title=MediaWiki:Common.css&diff=256393&oldid=256389) so I guess we will not know before long...

Yes, we noticed the path inconsistency when upgrading LinguaLibre to Mediawiki 1.35 as it broke some tools (including but not limited to Blazegraph).

FYI, I just created of first short draft for stopwords: https://github.com/belett/Breton_lexicography/blob/main/Stopwords%20br

https://www.wikidata.org/wiki/User:Teester/EntityShape.js is not exactly the tool describe in this task but it's an example of a « simple tool for checking Wikidata »

See also Wikidata:SPARQL_query_service/queries/examples/fr#Requête_de_lexème.

I don't think we really have a tool for that.

The problem came from old corrupted file (File page was still there but not the files themselves).
Once these file were deleted, the error message disappeared.
Maybe there is still some lost files somewhere but I think we can close this task.

Sadly I know the problem, not the solution...

@Yug create lexemes would be very nice but quite difficult. "language + form" is not enough, at least the lexical category is mandatory to create a Lexeme.
Other data are needed to to determine if the lexeme exists and is the same (for instance for cases like "fils" - threads L10371- and "fils" - son L15917 - or "tour" L2330 and "tour" L2331).
How could we solve these problems?

I also think a community consultation is not needed: this is an old historic file that make no sense for most Wikisource.

Yes, the problem is still here and open.

This is a great idea.

I'm copy-pasting/translating some remarks from @Denis_Gagne52 (who in not familiar with Phabricator) on the fr.ws scriptorium.

I can confirm that it seems to be fixed.

Just a quick update, we definitely need the distinction between "ñ" and "n".
It's quite rare but there is some pair of word where the tilde is the only distinction, for instance mañ ("this") and man ("he/she stays" but also "moss").

Maybe we can store the list somewhere online (on a wiki page ? on a pad ? either is good for me) and do a collective review (strike the wrods that are not really stopwords, for instance all the numbers are not really stopwords, there is adverb too I'm not sure we should keep).

I strongly agree.

Hi @Aklapper go on any page on any Wikimedia projects, you'll see that some label are not retrieve and the Wikidata Q identifier (or P identifier) is displayed instead.

Thanks for the merge @Charlotte

@Gehel very true. That said, it won't hurt performances either and what about all the other problems of not being able to stop a query? (I hate when I have to restart my browser and/or computer who froze just because I dumbly forgot to remove a wdt:P279*)

Sorry about the ping then.

Hello, is someone working on this ? Thanks.

More exactly: the code fr-ca works fine (everywhere AFAIK) but for some reason the name "français canadien" doesn't appears on the list (everywhere AFAIK). I think this is a different and separate bug and a new ticket would be more appropriate.

Some precision: apparently (from what I've seen) it appears only in English and French and only for the P195 property.

In T233188#5509703, @MSantos wrote:

Could this changeset delete 2 duplicated nodes be related? https://www.openstreetmap.org/changeset/74624620

In T230767#5456114, @Romaine wrote:

In multiple campaigns people tried to re-enable it, like https://commons.wikimedia.org/w/index.php?title=Campaign:wlm-pt&diff=prev&oldid=363866712

FYI, there is a table at the hackathon working on it right now, at least looking at the first possible obstacle.

And now it seems that http://wikidata.rawgraphs.io/ doesn't work at all any more :/
If it's not temporary then we should probably remove the link altogether :(