Marking this as stalled for now with a note to reopen once AMC is more widely available.

Wikidata should be accessible to mobile Wikipedia readers, not just advanced mobile contributors.

The idea is that one could navigate to the mobile view of Wikidata. I don't actually suggest that people should use a mobile to contribute to Wikidata nor be required to log-in to view Wikidata.

off-topic: what is cool is that it displays images (which www.wikidata.org doesn't)

Why is there such a "need"?

For harvesttemplates, it would be great if this could be queried/defined somewhere

We could use the https://www.wikidata.org/wiki/Q64335281 approach. Also solves the problem of structured data on EntitySchemas.

A problem we had with the Russian gadget is that people try to "update" information from the client instead of adding a new statement, e.g. change 2019 to 18 June 2019. In general, this isn't much of an issue for this type of edit except when the statement on Wikidata includes a reference stating "2019" and not "18 June 2019". Even a typo could be something that requires a new statement.

Simple solution could be to use items instead, see https://www.wikidata.org/wiki/Q64335281

I changed the sample in the description above.

+ check items against EntitySchemas

As PetScan has some troubles these days, I'm using query server/mwapi:generator "categorymembers" again.

Wikidata has most of that: https://www.wikidata.org/wiki/Wikidata:Database_reports/WMF_projects

Maybe it should be a Wikimedia-Site-requests or an interwiki one.

np. I made E27 directly .. bad news is: now I have to come up with items that match the scheme ;)

good point .

We used to have an url property that was suitable for that .. not sure where it went.

Somehow I like the summary. Anyways, here it is for future reference

Depending on the browser I use, I get "Javascript is disabled or slow to load or something went a bit pear-shaped." during the initial load. Could you increase the time-out?

I'm not sure if that can be sorted out. There seems to be lots of politics and possible conflicts of interests involved, none really related to the simple issue at hand.

Currently, I don't think the constraint system allows to limit a constraint scope to items only.

The IPA statement on Q102090 isn't really a sample to follow.

I don't think the wdtn triples are needed. I'd just add the "wikibase:identifier" ones.

P407 isn't needed on lexemes. Even, I asked them not to add it.

You'd need that if most content you want to enter is directly in UPA

Do you want to create codes that allow entering UPA directly? e.g. "sms-fonupa" ?

The current (above) format of the triples (when it works) seems fine from a Wikidata perspective, but from a LOD perspective, shouldn't the triple just be something like:

Suggestions are better than before, but I think a review should be done to see what is still open and what could be improved further.

Maybe you want to add support for replacement_property as well.

For (non-contemporary) people, I think an interesting grouping could be by century, but I'm not entirely sure how that could work without a dedicated statement.

Not sure if this is relevant here, but the most frequent unhappy paths I notice are:

It seems to using grouping_threshold .. I noticed that when I started using a fairly high one.

For grouping by some sub-national level, maybe a separate query to get levels first is the most efficient. A shorthand for that could be a P31 statement or a property (if there is one).

Anyways, thanks for adding so many of the suggestions. I'm aware that it's usually up to the coders to pick them.

E27: scheme for lightbulbs . per https://en.wikipedia.org/wiki/Edison_screw

maybe items with Q5 could have separates stats.

I picked E55 from https://en.wikipedia.org/wiki/European_route mainly because it's a longer one that runs through Berlin (where WMDE offices are). E40 is a good choice too.

Some not so random suggestions:

new feature?

Independently of the above, is there a way to use CONSTRUCT ?

Alternative: query by units. Sample: https://www.wikidata.org/wiki/Property_talk:P6591#Query_with_%C2%B0F/%C2%B0C_conversion

What is needed to run the generator just once, at least once for a given variable?

Apparently codes for lexemes are distinct from monolingual ones. We could solve this first and wait for the other to be sorted out . or whatever.

Interesting. "mad" outputs more than "max" ;)

Not that it changes the problem, but the current URL should have preferred rank and the former url normal rank. See https://www.wikidata.org/wiki/Help:Ranking#Deprecated_rank

Thanks to both of you. I tested the workaround on the sandbox item above and it worked.

I tried it there just now: the first worked, the second didn't.

I don't use it that often, but I think it didn't work every time in recent weeks.

It's two years now.

q="don't escape the backslash" :)

So you think it's not possible to link some of the queries to specific users?

Clearly we disagree on the proposed release, its scope and users expectations for privacy. If one thinks it's normal to publish users search history, the arguments you advance are probably a valid point of view.

Maybe page properties should include counts of lemmas, forms and senses, as they do for statements and identifiers.

Do we have any discussion of this usecase onwiki? It seems contrary to a problem raised onwiki.