datatype of property in sample is "monolingual text ", not "multilingual text".

Oh, sure; you're right, @Esc3300. Thanks for catching that. I'll update the ticket.

It could display something like
Changed claim: title (P1476): Wikidata@mul
instead of
Changed claim: title (P1476): Wikidata

I think we might be able to fit a language code into the edit summary without changing the format too much:

/* wbsetclaim-update:2||1 */ [[Property:P1549]]: бразильянка

It looks like there’s a free space between those two vertical bars which, in case of monolingual text statements, we could use for the language code.

Compare e.g. the edit summary when removing an alias:

/* wbsetaliases-remove:1|fr */ Bresil

(See API request for both edits.)

Yeah, the part after the first vertical bar is always a language code:

$commentArgs = array_merge(
	[ $summaryArgCount, $summary->getLanguageCode() ],
	$summary->getCommentArgs()
);

So if we make ClaimSummaryBuilder set the language of the summary object, it should show up in the autocomment part of the formatted summary. (Reminder: /* this is the autocomment */ this is the autosummary, and everything together is the summary.)

However, as far as I can tell, that wouldn’t allow us to show the language after the text, like on diff pages (“бразильянка (Russian)”). Each autocomment part is formatted independently, so if we go this way, the best we could do is something like “Changed Russian claim: demonym (P1549): бразильянка”. The monolingual text value is in the autosummary, not the autocomment, and we don’t have control over how the autosummary is displayed (after we assembled it in SummaryFormatter). (The only control we have over the autosummary is the links in there, where we render links to entities using their labels, but that’s a fairly separate thing.)

I suspect that putting the language code in the autosummary, together with the value, will be better, even if in that case we can’t format it as a language name either. But then we need some feedback from Product whether the syntax proposed by @Esc3300 (text@code) is acceptable, or it should be something else.

Thanks for looking into this.

The problem with the language code for monolingual strings is that it's part of the value and it can change in the edit.

I suppose it's generally preferred to have the language spelled out and localized.

The format “бразильянка (Russian)” might suggest it's part of the value. Something "@ru" doesn't.

If there is a clever way to include it in the autoedit summary, that would be fine for me.

Thank you @Lucas_Werkmeister_WMDE for the research and the summary! The proposed syntax would essentially work. At the same time, I would love us to be as consistent as possible with how we do this elsewhere. So if the first vertical bar is always the language code, then I would prefer us to use that if sensible.

Something like “Changed Russian claim: demonym (P1549): бразильянка” would make sense to me.

Does anyone here have Feedback on this?

Is there a way to do “Changed claim: demonym (P1549) in Russian: бразильянка”?

(Just adapted the sample given above, "бразильянка" seems to be translated as "Brazilian")

As the language is part of the value and not of the predicate, I think it's better to display it close to the value.

Maybe my comment wasn't clear. For the sample above this would be "NEW "Changed claim: title (P1476) in Thai: Wikidata"". Updated that.

@Esc3300 Thank you for clarifying what you meant. While the changed description is of course better to read, this might change the technical implementation more than I would want. I take this ticket back for now, as it seems to still need some discussions.