msglist: Use directional positioning for unread marker in RTL

[yash-agarwa-l]

Fixes #1245

This PR corrects the unread-marker alignment in RTL layouts.

Problem:
_UnreadMarker used LTR-specific properties (left: 0, Border(left: …)), causing the unread marker to always appear on the left, even for RTL languages like Arabic.

Fix
Therefore Replaced LTR-specific properties with directional equivalents:
PositionedDirectional(start: 0)
BorderDirectional(start: BorderSide(...))

This ensures the unread marker appears on the correct “start” side based on text direction.

Manually tested by setting:
locale: Locale('ar')

Verified correct behavior in both LTR and RTL layouts (screenshots included).

Before

LTR

RTL

After

LTR

RTL

[chrisbobbe]

Thanks! Small comments below.

Also:

• Please say Fixes #1245. in the commit message. For examples, use Greg's "secret" to using git log -p.
• Please also post screenshots of what it looks like before this change, so we can see clearly the improvement being made. 🙂

[chrisbobbe]

Same here.

[chrisbobbe]

This code-style change is unrelated and unhelpful; please remove it.

[yash-agarwa-l]

Thank you for the feedback.
I’ve cleaned up the commit and added the before screenshots as requested.
Please let me know if there’s anything else I should adjust.

[chrisbobbe]

Bump on this part:

• Please say Fixes #1245. in the commit message. For examples, use Greg's "secret" to using git log -p.

[yash-agarwa-l]

Thank You, I've updated the commit and pushed the revision.

[chrisbobbe]

Please write it according to the project style; the Fixes #1245. line belongs in the commit-message body, not in the summary line.

[yash-agarwa-l]

Thanks for the clarification, updated.

[chrisbobbe]

Thanks! Marked for Greg's review.

[gnprice]

Thanks @yash-agarwa-l for taking care of this, and thanks @chrisbobbe for the previous reviews!

Those before/after screenshots in particular are very helpful, thanks. It's especially helpful that they're very clean — the before and after differ only in the one way that's relevant.

This looks good; merging. One commit-message nit which I'll fix up:

-    msglist: Use directional positioning for unread marker in RTL.
+    msglist: Use directional positioning for unread marker in RTL

In this repo we don't use a trailing period on the summary line of a commit message.

[gnprice]

I also just did a quick audit with git grep left: and git grep right: to look for other similar places to be fixed. (More precisely: git grep -iP 'left:|right:' lib/. Some matches for that query treat left and right symmetrically already, so those are fine.)

I found 4 of them:

• The formatting on block quotations (the Quotation widget).

• The display of images and video thumbnails in the message list. That's the MessageMediaContainer, here:

      child: UnconstrainedBox(
        alignment: Alignment.centerLeft,
        child: Padding(
          // TODO clean up this padding by imitating web less precisely;
          //   in particular, avoid adding loose whitespace at end of message.
          padding: const EdgeInsets.only(right: 5, bottom: 5),

• In ReactionButtons, there are two references to BorderRadius.only which use topLeft and topRight respectively. I suspect those are wrong in RTL locales.

• We have an icon chevron_right. Probably each place that's used is an example of this bug. … I guess this one is tracked as RTL: Flip directional icons, like chevron_right and send, in RTL mode #1907.

@yash-agarwa-l if you're looking for more issues to work on for contributing to Zulip, I think those would be a good list to pick up while this area is fresh in your mind from doing this issue.

I'd suggest going in the order listed above — the quotes in particular I would guess look pretty wrong right now. And then a key element in a PR for any of these will be to post good before/after screenshots that clearly show the change, just like you did on this PR.

[yash-agarwa-l]

Thanks so much for the review, the merge, and especially for auditing the code for these related RTL issues!

I'm really happy contributing to Zulip. I'll start working through that list, beginning with the block quotations (Quotation widget), and will keep all your feedback in mind for the new PR.

[gnprice]

Looking at the screenshots in #2005, there's one other discrepancy I notice (in main, not new in that PR):

• The "TODAY" in a recipient header is nicely aligned with the timestamps on individual messages in an LTR layout, but it's closer to the edge of the screen in an RTL layout.

That isn't one of the places I found in my comment above. It looks like that's due to one more pattern to search for: git grep LTRB lib/. Those are fine when the "left" and "right" arguments are equal, but should be converted to STEB when they're different. Looking at the results, there's just one of them to be fixed, happily — the same one that causes the discrepancy I spotted in the screenshots.

[yash-agarwa-l]

Thanks! I ran git grep LTRB lib/ and found the one instance where the left and right values differed. I've opened PR #2038 to fix it.

[gnprice]

@yash-agarwa-l Thanks again for all these fixes! Rerunning the search from #1991 (comment) now that the items mentioned there are all fixed, I find one more case which I missed earlier:

• In showing ScrollToBottomButton, we place it at the bottom and right of the message list. It should be at the bottom and end.

Would you be up for taking care of that? With good clear screenshots and a test, like you've been doing for these other issues.

[yash-agarwa-l]

Sure, happy to take care of that! I've made a PR for this fix (#2063) with the screenshots attached.

[gnprice]

OK, now that all those are fixed (thanks again @yash-agarwa-l!), I've gone and done a more comprehensive search: git grep -iP 'left|right' lib/. Most of the remaining matches are perfectly fine — including comments using the word "right" meaning "correct", or "left" meaning "remaining".

There are just two now that I think are suspect:

• In _AutocompleteFieldState, we have an Align with alignment: Alignment.bottomLeft. I expect this affects where the autocomplete results are shown.
• In UnicodeEmojiWidget, we have a Stack with alignment: Alignment.centerLeft. I expect this affects how Unicode emoji appear on iOS.

There are also a few classes of matches which look suspicious on their face, but I think are fine:

• In KaTeX content, several bits that translate layout directly from the KaTeX HTML which also uses "left" and "right". Similarly TableColumnTextAlignment in other content.
• Calls to the String.padLeft method, which would more aptly be named padStart.
• Icons with "left" and/or "right" in their names. We've already caused those to effectively mean "start" and "end", with icons: Add matchTextDirection to directional icons #2015.

@yash-agarwa-l would you be up for resolving those last two cases?

If you don't have a Mac for development then I think you won't be able to effectively test the second one — it relates to the idiosyncratic properties of Apple's proprietary emoji font. In that case we'll just leave that one for someone else to pick up.

[yash-agarwa-l]

Thanks! I'll take care of both of those. I do have a Mac, so I can properly test the UnicodeEmojiWidget changes as well.