Screenshots of the WIP patch:

In this case the page needed to be updated not because the keys on any system changed, but because the hostname was changed to point to a different system (tools-sgebastion-[06→07], due to the WMCS incident).

Decision: we’ll go with a configurable limit that defaults to a lower value, e. g. 50 000 bytes. This will also be indicated client-side via a maxlength on the inputs. (We’ll consider improving the browser’s default behavior for maxlength – just stopping to type / paste more input is a bit user-unfriendly.)

Decision: we’ll go with a special page. The name should probably start with “Schema” so that it’s grouped with other schema things on the list of special pages; it can be something other than “SchemaText” though.

The longest automatically inferred schema by the Wikidata Shape Expressions Inference tool is #23 at 718 039 bytes. MediaWiki’s default $wgMaxArticleSize is 2048 “kilobytes” (presumably kibibytes, i. e. 2048×2048 = 4 194 304 bytes?), so some schema length limit around one or two million bytes should be enough to store even large auto-generated schemas while not exceeding the underlying MediaWiki limit.

This could either be implemented as a special page (e. g. Special:SchemaText/O1, similar to Special:EntityData/Q1) or as an action (e. g. index.php?action=schematext&title=Schema:O1). I guess a special page is slightly more convenient because you don’t need to know about the Schema: namespace, and it’s also more discoverable (via Special:SpecialPages).

The Wikibase build went through, I was just about to close this when I saw your comment :) let’s call this resolved for now.

There are also similar errors in the unrelated change https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/490358. That said, the core change @Anomie mentioned has now been merged, so this might have been fixed in the meantime – I’ll recheck the Wikibase one.

Thanks, the flag looks good! Appropriately inconspicuous :)

term_type, small table holding the types of strings to be indexed in the db, right now this would be labels, descriptions and aliases, but this would scale to allowing more similar terms into the index (if desired) It might be the case not having a table here would be better and just keep INT ids in code.

I think the FormatAutocomments hook only comes into play later: that is only concerned with the comment text, and should run after the comment text has been generated from the comment data or message. I don’t think we can access the full comment object in there.

It turns out I slightly misunderstood the comment data field. While we can use it to store arbitrary JSON data, what we’re supposed to do (if I understand correctly) is pass a Message object into CommentStoreComment::newUnsavedComment(). The CommentStore will then take care of serializing and deserializing this Message, including its arguments, using the comment_data field, which we don’t use otherwise. (It even does this in a fashion that avoids conflicts with our own data, should we still have any, isn’t that nice?)

Note that this demonstrates the problem Thiemo mentioned in T95553#3916063: we currently can’t parse «9e siècle».

This also doesn’t occur in the Wikibase RDF export:

As outlined in T215296, we’re not going this way after all.

We decided that we’re not going to extract this new library after all (my preliminary patch Id635a82f4a already indicates that the split might not be as clean as we hoped). Instead, we’ll implement this independently from Wikibase, and experiment with using the comment_data field in the new comment table instead of just the comment text. The experience we gather here should hopefully also help us with T215422 in Wikibase.

“Summaries” also sounds misleading to me – I would prefer at least “EditSummaries” so it doesn’t sound like a summary of a Wikipedia article or something like that.

I went ahead and implemented the part of this that can already be done without a new Gerrit repository: splitting the Wikibase code into what will be extracted and what will stay in Wikibase.

These patches are now on Gerrit, starting at I97aaa69748.

I get the impression that “edit summary” is the user-facing term and “comment” the developer-facing term (see e. g. the comment table). And I think something emphasizing the functionality would make more sense, i. e. I’d prefer “multilingual comments” (what the extension provides) over “comment auto-formatter” (one of its compontents).

The labels are already available via RDF, see e. g. M76321298.rdf. (The entity ID is “M” plus the page ID of the file, which you can see e. g. on the “page information” page.)

For now, this task is only about adding a summary field to the “edit” page (after the label/description/aliases fields have been removed there, see T214466). The automatic / translatable part is part of other tasks.

• add an “edit” link to Special:SetSchema… on the page
• add an “edit“ link to ?action=edit on the page
• remove main “edit” tab

• add some special page like Special:SetSchemaLabelDescriptionAliases
  • which uses automatic translatable summaries T214887
• remove label/description/aliases fields from main edit page

• implement translatable automatic summaries for editing labels/descriptions/aliases T214466
  • doesn’t have to detect which part was actually edited, at least not for now
• implement translatable automatic summaries for editing schema text, in addition to custom summary (edited schema: bla bla)
  • add summary field to edit page

In T208489#4927936, @Lydia_Pintscher wrote:

In T208489#4926384, @Mahir256 wrote:

Ideas regarding the open questions in the task description:

• Yes. As a matter of fact, since the datatype opens up the possibility for more specific properties to be defined, values of this property could be migrated to those specific properties and the original property could be deleted afterwards.

I was thinking if we can/want to do an automatic conversion in the database like we have converted some string properties to external identifiers in the past. Apparently we can do that conversion.

To me it looks similarly broken, but with a different error message: