I did, but it doesn't solve it for WMF in general nor address the root problem

This isn't limited to Listeria, all toolforge domains seem to be affected:

• https://quickstatements.toolforge.org/
• https://toolforge.org/

If it's a known issue with the certificate WMF is using, why not change it?

In T285156#7388535, @Lydia_Pintscher wrote:

• Could this solution somehow backfire? -> several answers in this thread that we will weigh and see if they warrant any action

Can you propose something?

If this is the only open point, can you summarize how the open points mentioned in the task description had been addressed ?

Apparently there is a disagreement between Lucas and his manager about description editing.

In T285156#7388192, @Mahir256 wrote:

please refrain from editing the task description while the discussion is ongoing. It is inappropriate to masquerade your personal opinion as the hard-won consensus that we are trying to achieve here.

This message (especially the latter part) is enough of a reason

In T285156#7388183, @Lydia_Pintscher wrote:

@Esc3300 For clarification: Lucas and I spent a lot of time yesterday on getting everything to a point where we believe it is sensible and the remaining questions are clarified. It'd be good to concentrate the discussion on those remaining points now

Can you explain the reminder of your deletions? Above what you deleted from the description.

Changes for task description are:

Odd that some of known issues shouldn't be stated in the task description.

@Lucas_Werkmeister_WMDE that should have been. I removed Mahir256 as they seem to be doing nonsensical edits to subscribers.

@LucasWerkmeister Can you outline which of the deleted points you consider problematic? Lydia generally wants to summary in task descriptions to be up-to date. If you just remove stuff, we are missing out on information.

OTH, name items only need one label and transliterations could go into statements. So the setting would be "mul" + name > no other labels.

The problem with "mul" is that we couldn't easily have the software test if there should be ru/uk label (as for "John"), but no la/fr/en label on items.

@Epidosis for that sample, it seems clear-cut, but for Q191118 one could imagine Cyrillic "т" as "mul" label.

@Epidosis What should happen when mul is in Cyrillic ? You seem to assume mul-latn.

Agree with that. Already T289473 seemed rare to me.

Couldn't we save a lot by simplifying descriptions? (saving which template applies instead of storing the actual string for every language).

Interesting data, the question is what conclusions to draw from it for practical usecases at Wikidata.

Isn't that what property suggestor does?

Depending on how it's solved for the template, it might do it for Wikidata as well.

It seems the request is unrelated to Wikidata. Maybe you want to edit the description to make this clear.

I added short summary about the current situation at Help:Dates#Hours,_minutes_and_seconds.

If the use is for an English Wikipedia template, shouldn't additions be required there?

In T290857#7347938, @Mohammed_Sadat_WMDE wrote:

@Amire80 Could you confirm whether these languages have valid IETF language tags.

please add samples

From the explanation given by @So9q on project chat, it seems interesting to be able to use (or learn to use) other graph languages, such as Gremlin.

A reason we started adding identical labels to different languages for family name / given name items is to avoid that users try to translate the label, e.g. family name "Taylor"@en shouldn't have "Tailleur"@fr "Schneider"@de. In languages with different scripts, transliterations are ok.

Recent sample:

• https://www.wikidata.org/wiki/Q108028460
• https://www.wikidata.org/wiki/Q108028461
• both created by the same tool with sitelink to https://en.wikipedia.org/wiki/John_David_McKie

I don't want to dig on this further. Thanks for having it fixed.

I think it needs ?uselang=en for the link to work if you are logged-in and not using English. It's still on the linked project chat page.

From T263946 it looks like it followed the usual process for new codes for Wikidata. Also it was tested/marked as resolved by WMDE staff.

Let me try to translate contributor speak to something actionable:

Test onwiki: constraint addition, sample statement

@Lydia_Pintscher can WMDE pick this up? It's a fix to something that previously slipped through the checks.

@jhsoby do you want to be pinged or did you already see this as you are also following workboard/project directly?

To find them: gil.

I'm not sure if everybody knows what "60s" or "162s" (what may seem quick) actually means to editors: it's the time they wait between creating the item and adding it as a statement value (which there seems long).

It's actually more of a subtask, simple, understandable and straightforward to implement.

If you just want to add statements with https://www.wikidata.org/wiki/Property:P1843 enabling the code for monolingual text properties is sufficient.

@Mbch331 if you have a moment, would you patch this? Alternatively, I would have to ask WMDE. It's a potentially problematic ambiguity.

The sample is for a label, but the request is for "monolingual text". Which one do you want?

So langcom review isn't needed here? Ok.

For clarity's sake, maybe we should hold discussions about editorial choices on Wikidata directly. Also langcom members should stated that they are expressing the langcom view and reference the policy or procedure they are using to base their argument on. It may also be preferable if, when a user who is a langcom member, requests a new code, they don't express any langcom view on the code. Alternatively, it may seem that the process is somewhat random or arbitrary.

Good question about the fallback. Currently the fallback is to "en", so maybe the fallback for English (or French) should be:

Good. Just noticed that we discussed this 3 years ago .. on talk of that help page. Maybe flag it for follow-up in 2024 then ;)

BTW, I noted it as an exception at Help:Property_constraints_portal/Property_Scope_Constraint. Obviously, it applies to other constraints too, but less importantly so.

Here is a sample of the uniqueness count I had in mind https://w.wiki/3ub4 . The sample is only across three items.

When doing this, please add "is a list of" (P360) as well.

I added some of the participants of the related property proposal discussions as subscribers.

It could be interesting to get this to work for identifiers that are re-assigned, e.g. ISO country codes or airport codes.

Seems that there was an attempt to implement this in August 2013: T53071 , abandoned in March 2014 after a few code rewrite requests weren't addressed: https://gerrit.wikimedia.org/r/81001

It's explained at https://phabricator.wikimedia.org/project/profile/4981/

Given the absence of samples

Given some of the samples, I suppose we should have both, "mul" and "mul-<script>".

@dcausse would you re-run the script this week? We deleted a series of items last weekend on WD

@Manuel is this in any way related to this request ? While general questions can be interesting, they tend be not easily solved in wikis. T51024 (from 2013) might have waited for that too.

We now have author names a detailed strings, so queries to P50 wont necessarily need to be considered.

The ticket is about English names of languages and autonyms (as per its title).

raw data for this is regularly updated onwiki by the community

@Manuel does this need more input or can this move ahead?

It worked on Wikidata. Is ok now or is some other feature needed?

all requests are done. Please create new requests for additional languages.

What's also missing are specific usage samples (labels or monlingual string values that could be added with the code). ( T263946 isn't really helping, as it was done without following the outlined approach )

It works for the four above. Shall we close this as done?

I don't think we should change behavior on diffs and reverts for this feature only and potentially create incomprehensible reverts hiding content.