Lucas_Werkmeister_WMDE created this task.
Lucas_Werkmeister_WMDE added projects: MediaWiki-Comment-backend, Wikidata, 
Shape Expressions.
Restricted Application added a subscriber: Aklapper.

TASK DESCRIPTION
  The `CommentStoreComment` class, encapsulating a comment (edit summary, log 
message, etc.), was added as part of the big comment refactoring in T166732 
<https://phabricator.wikimedia.org/T166732>. It can contain not only a plain 
string `text`, but also a `Message` and additional JSON data. If a `Message` is 
present, the `text` is supposed to reflect that message in the content 
language, but the `Message` may be used to render the comment in the user 
language instead. Wikibase currently achieves a similar result via the 
`FormatAutocomments` hook, but `CommentStoreComment` has the potential to be a 
nicer and more general solution.
  
  However, the class is currently not used to its full potential. 
`CommentStore` is responsible for saving and loading `CommentStoreComments`, 
but most of the places that use it to load a comment discard the comment object 
pretty soon and only use its text, equivalent to the old comment field prior to 
the comment refactoring. We should change this, use `CommentStoreComment` 
objects as much as possible, and render them properly, including translation 
via the message if possible.
  
  ---
  
  How exactly this proper rendering looks like, though, is not yet clear. The 
most conservative approach, and what I think seems to have been intended during 
the design of the new comment system, is to take the `->text()` format of the 
message and format it just like a regular comment (i. e. 
`Linker::formatComment`: sanitize, format /*autocomments*/, format [[links]]). 
However, this system is fairly limited in the formatting of the message, and it 
also means that any comment syntax in the message will be formatted, whether 
that was intended or not (e. g. plaintext params of the message would not 
really be plain text). In other words, while the message may contain structured 
information about the comment, this approach would not make use of it. To me, 
this would be passing up an opportunity to solve bugs like T186035 
<https://phabricator.wikimedia.org/T186035> and T215929 
<https://phabricator.wikimedia.org/T215929>. (It is possible to fix those bugs 
in other ways – @Anomie suggested using invisible characters, like `U+200B`, to 
escape parts of the message – but that would have to happen before constructing 
the message.)
  
  Another approach is to `->parse()` the message, if it exists, and bypass the 
usual comment formatting. This gives the creators of the 
`CommentStoreComment`s, e. g. Wikibase, much greater flexibility: they can use 
full Wikitext parsing in the summary, and parameters would be correctly escaped 
according to their type (e. g. plaintext params would stay plain text). 
However, this is not fully compatible with the original comment model: that the 
comment text corresponds to the `->text()` of the comment message in the 
content language. Instead, the comment text here would contain arbitrary 
Wikitext, and anyone who uses the comment text instead of the 
`CommentStoreComment` proper would just see the Wikitext. Within MediaWiki, 
this would mean we should migrate to `CommentStoreComment` fairly quickly; but 
users of the `comment.comment_text` field on the replica databases, or of the 
`comment` revision prop in the API (as opposed to `parsedcomment`, which would 
now actually `->parse()` the comment), would still be affected.
  
  @daniel had an idea to mitigate this problem, though: creators of 
`CommentStoreComment`s, e. g. Wikibase, could override the `->text` field of 
the `CommentStoreComment` to be a more suitable textual form of the message, 
instead of the `->text()` of the message, before passing it to `CommentStore` 
(or `PageUpdater::saveRevision()`, etc.). In the trivial case, this could just 
be “textual comment not supported”, but they could also format a simpler 
version of the message, or check if arguments need to be escaped with `U+200B` 
or similar.

TASK DETAIL
  https://phabricator.wikimedia.org/T218127

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Lucas_Werkmeister_WMDE
Cc: Aklapper, Lucas_Werkmeister_WMDE, Anomie, daniel, pdehaye, alaa_wmde, 
Michael, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, 
YULdigitalpreservation, LawExplorer, Salgo60, _jensen, rosalieper, MGChecker, 
abian, Wikidata-bugs, aude, Dinoguy1000, Lydia_Pintscher, Mbch331
_______________________________________________
Wikidata-bugs mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to