Page MenuHomePhabricator

Long edit comments get entirely removed instead of truncated (error in cutting multibyte chars?)
Closed, ResolvedPublic

Description

Since september if some action creates too long automatic comment (page protection, mass edits reverting...) in ruwiki, this comment not crops, but entirely removes, see https://ru.wikipedia.org/w/index.php?title=Википедия:Именование_статей/Иноязычные_названия&diff=prev&oldid=65843747 (page protection). Perhaps the reason is that the Cyrillic chars occupy 2 bytes in UTF-8 - before that this chars were cut off in the middle and turns into a "question mark in rhombus" symbol, since the beginning of the problems I have not seen this symbol. More examples on https://ru.wikipedia.org/w/index.php?title=Википедия:Форум/Архив/Технический/2014/09#Утеря_описания_правки_при_откате_изменений

Event Timeline

MBH raised the priority of this task from to Needs Triage.
MBH updated the task description. (Show Details)
MBH subscribed.
Ciencia_Al_Poder renamed this task from Long autogenerated edit comments entirely removes to Long autogenerated edit comments entirely removed from page history, but not from logs.Jan 2 2015, 4:25 PM
Ciencia_Al_Poder updated the task description. (Show Details)
Ciencia_Al_Poder set Security to None.
MBH renamed this task from Long autogenerated edit comments entirely removed from page history, but not from logs to Long autogenerated edit comments entirely removes because error in cutting multibyte chars.Jan 2 2015, 4:25 PM
MBH updated the task description. (Show Details)
MBH removed a project: MediaWiki-Page-editing.
Aklapper renamed this task from Long autogenerated edit comments entirely removes because error in cutting multibyte chars to Long edit comments get entirely removed instead of truncated (error in cutting multibyte chars?).Jan 2 2015, 5:44 PM
Aklapper triaged this task as High priority.
Aklapper added a project: I18n.

(Offtopic, but problem would be less visible if T6715 got fixed)

Not sure if this is still Core or already DB territory. Probably the former if MW does not cut properly and garbage ends up in the DB

Change 191971 had a related patch set uploaded (by Umherirrender):
Truncate protect reason on null revision for whole multibyte characters

https://gerrit.wikimedia.org/r/191971

Patch-For-Review

Change 192001 had a related patch set uploaded (by Umherirrender):
Remove half bytes when showing comments

https://gerrit.wikimedia.org/r/192001

Patch-For-Review

In T85700#1075849, @MaxBioHazard wrote:

not fixed

Correct, as this task still has status "Open". No need to tell. :)

Change 191971 merged by jenkins-bot:
Truncate null revision comment for whole multibyte characters

https://gerrit.wikimedia.org/r/191971

With version 1.25wmf22 new long comments for revision will be truncated correctly, but still old comments are not shown.

Aklapper lowered the priority of this task from High to Lowest.Mar 18 2015, 5:47 PM

Thanks! Lowering priority accordingly.

Aklapper raised the priority of this task from Lowest to Medium.Mar 18 2015, 5:52 PM

Uh, 2nd patch still waiting (sorry didn't see that at my previous comment), hence putting Priority to normal.

Change 192001 abandoned by Umherirrender:
Remove half bytes when showing comments

Reason:
Too complicated

https://gerrit.wikimedia.org/r/192001

The problem with new too long comments is solved. For the existing log reasons I have created a new task T95353 to handle that.

In T85700#1251861, @MaxBioHazard wrote:

This is a new issue (first was about protection summary, this is about flagged revs). I have created T97883 to track the issue and allow the right project assigned.

This is issue about entire problem, not about protection only (see OP post), why you close it and create duplicate ticket?

The original post includes page protection which was fixed. It is easier to have one task for one issue, because than a devoloper does not have to read the whole task and needs to look which is already fixed.
The feature behind "mass edits reverting" was unknown to me, why I have read over it, but it seems it is the reject feature of flagged revs, where I created an own task for the correct project.

In T85700#2906207, @MaxBioHazard wrote:

Thats already tracked as T97883, see https://ru.wikipedia.org/w/api.php?action=query&prop=revisions&revids=82746538&format=xml for the reason, which is a FlaggedRevs summary text (message revreview-reject-summary-cur)