An idea that seems plausible for tackling this is exploring the use of a tool-tip. A user may hover their cursor over a date against an edit summary to view more information (in this case, the date) for the edit summary. The number of characters in a date, depending on the language the interface is in, will definitely vary. The tool-tip should give us a consistent and predictable interaction for the user. @Pginer-WMF, any thoughts on this?

In T308720#8103672, @Wangombe wrote:

An idea that seems plausible for tackling this is exploring the use of a tool-tip. A user may hover their cursor over a date against an edit summary to view more information (in this case, the date) for the edit summary. The number of characters in a date, depending on the language the interface is in, will definitely vary. The tool-tip should give us a consistent and predictable interaction for the user. @Pginer-WMF, any thoughts on this?

Tooltips can be useful to show additional information. Preferably complementary info that is not essential, since user on some devices (e.g., touch screens) may lack this support. In this context, tooltips can be useful, however it is not clear to me in you proposal which info you suggest reducing. Is the idea to crop the message when it is tool long (e.g. using ellipsis)?

I think cropping in this case could work since this is more of a summary view, and users can access to a detailed view with all the info. The tooltips can work as a time-saver on top of that for a quick check.

The date is the concern in this case as it wraps to the next line depending on its length (making the UI appear broken). As one can imagine, localised dates would have a different number of characters; some longer than others. I do wonder if having the tooltip would add an extra layer for the user to click [on the full date] to access more information about the edit summary item.

I was also wondering if we could just have the date and the summary text without any spacing in between as a continuous text. Something similar to:

Yesterday at 16:45 · Added some more spacing

OR

Added some more spacing · Yesterday at 16:45

The · here is the separator but we could use a more visible separator as well. This way if the date text or summary text is long the text would wrap and would not look out of place.

I created mockups for some of the solutions to make sure we are on the same page when analyzing them:

A. Use only relative dates without time

Showing a broad and relative time reference should be compact enough to avoid wrapping issues inmost cases: "today", "yesterday", "2 days ago". It does not show the time (and multiple changes on the same day would just display the same label) but those interested in more precision can click on the link and get the details. A tooltip can be shown alos on hover with a more detailed date (similar to next solution).

B. Copping + Tooltip

Limit the date/time information to only one line and crop the rest with ellipsis. On larger screens users may get the whole text. On smaller screens, users may get a part of it that may be enough to provide a general idea. A tooltip when hovering can provide the whole information, and tapping on it provides access to a page with all the details if needed.

For both A, and B, it can be adjusted how much space is reserved for the description and how much for the date/time information to try to provide enough space for the info to fit in most cases.

C. Dates first

D. Date follows description

Showing the dates right after the description results in a single line of content which fragments less the space and makes wrapping less frequent. However, this makes such line heavier by containing more information that may be secondary the main focus is on and breaks the alignment with the option to view all changes (that was a continuation to access the rest of the updates).

If our main purpose is to provide quick access to context about what changed (with other aspects such as when or getting to all details to be secondary) I think my preference goes along the lines of A. Preferring B and D over C.

Solution A may make the issue less severe, but won’t solve it. For example, the translation of 4 days ago (10 characters) into Sakha (sah) is 4 күн ынараа өттүгэр (20 characters), and there may be even longer languages.

I do like approach A and B more because they appear less busy, but I think they will not work very well with touch devices so I would prefer to go with approach D.

Approach D seems to cover the needs of this ticket well.

In T308720#8115277, @Tacsipacsi wrote:

For example, the translation of 4 days ago (10 characters) into Sakha (sah) is 4 күн ынараа өттүгэр (20 characters), and there may be even longer languages.

With this in mind, I think we should still consider cropping the text should it exceed the width of the parent container. I will implement and test this.

In T308720#8122400, @Wangombe wrote:

With this in mind, I think we should still consider cropping the text should it exceed the width of the parent container.

In a one-column layout, I don’t think long dates look bad (they can break into multiple lines without breaking the layout); my comment was only about approach A.

In T308720#8123066, @Tacsipacsi wrote:

In a one-column layout, I don’t think long dates look bad (they can break into multiple lines without breaking the layout); my comment was only about approach A.

You're right. The default list decoration available on the <ul> tag makes the text readable even if it wraps to the next line because it provides some visual separation between the summaries. The date with the link is also legible in this format. The UI language is in Sakha (sah). One concern I have is the number of entries (5) pushes the translation memory out of view and extra scrolling is needed to access them. I don't think this is ideal for the translators experience.

The edit summaries may also not have a new update since translations may not change for a while. Showing 5 may be a bit excessive. I propose 3 entries to give room for the translation memory.

Change 822035 had a related patch set uploaded (by Wangombe; author: Wangombe):

[mediawiki/extensions/Translate@master] Wrap date text on previous edit summaries

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

In T308720#8141902, @Wangombe wrote:

In T308720#8123066, @Tacsipacsi wrote:

In a one-column layout, I don’t think long dates look bad (they can break into multiple lines without breaking the layout); my comment was only about approach A.

You're right. The default list decoration available on the <ul> tag makes the text readable even if it wraps to the next line because it provides some visual separation between the summaries. The date with the link is also legible in this format. The UI language is in Sakha (sah). One concern I have is the number of entries (5) pushes the translation memory out of view and extra scrolling is needed to access them. I don't think this is ideal for the translators experience.

The edit summaries may also not have a new update since translations may not change for a while. Showing 5 may be a bit excessive. I propose 3 entries to give room for the translation memory.

I cannot see the image in this message

If it’s sometimes too long, what about making it collapsed, similarly to the message documentation?

From the screenshot below, one can see what the summary and the timestamp looks like a normal wrapping piece of text. It provides a continuous flow of legibility. The number of bytes in the message have been capped at 60; It's slightly above the edit summary length average (54 bytes). The wrapping is more natural looking from this implementation.

Using approach C outlined by Pau allows us to use the the CSS wrapping functionality. This avoids issues that might arise out of cropping the content using JavaScript such as HTML tags being cut off.

This also has other benefits such as copying actually copies the entire content of the summary even though its not visible rather than the copying only the cropped off content.

Reverted back to approach D and used flexbox to crop the content.

A slight tweak to the previous change with the list item disc displayed:

Change 822035 merged by jenkins-bot:

[mediawiki/extensions/Translate@master] Wrap summary text on previous edit summaries

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

Real example from translatewiki.net:

I would still consider limiting the list to less than five items or making the editor taller. What do others think?

In T308720#8219956, @Nikerabbit wrote:

I would still consider limiting the list to less than five items or making the editor taller. What do others think?

I think the main value is to surface recent updates. I'd propose to show just 3 items. A short list is more inviting to take a quick look and make sense of it. There is an option to access the whole list in any case.

In T308720#8219956, @Nikerabbit wrote:

I would still consider limiting the list to less than five items or making the editor taller. What do others think?

I think so too. The Suggestions are important because I'd imagine the user interacts with it more than the edit summaries. I think having a quick look at edit summaries would be all a user needs to be curious enough to click on the option to access more of the summaries. 3 is a good number.

Change 830878 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):

[mediawiki/extensions/Translate@master] Edit summaries: Reduce number of edit summaries to 3

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

Change 830878 merged by jenkins-bot:

[mediawiki/extensions/Translate@master] Edit summaries: Reduce number of edit summaries to 3

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

I've reduced the number of summaries to 3. We can look at increasing the height of edit window so that more translation suggestions are visible.