matrix-react-sdk
matrix-react-sdk copied to clipboard
Correctly align messages in right to left languages
Fixes https://github.com/vector-im/element-web/issues/4771
Here's what your changelog entry will look like:
🐛 Bug Fixes
- Correctly align messages in right to left languages (#5453). Fixes vector-im/element-web#4771. Contributed by @aaronraimist.
It is needed to add dir="auto" HTML attribute to text placeholders. As far as I know this is not something to be solved effetively using only css.
Yes that already exists. The problem is it doesn’t do anything on a span element.
Yes that already exists. The problem is it doesn’t do anything on a span element.
I saw it just now on element desktop. I just modified the css with dev tools and the initial result is fine:
.mx_EventTile_body {
overflow-y: hidden; /* already exists */
text-align: start;
display: block;
}
I indicated rightly/wrongly aligned lines with some color coding on side. Those two red lines are wrong because I made those message using shift+enter so that they are posed in a single span. This is fine to me as it is manageable and understandable by the user. To me this is fine. I will try to check more complex cases.
I have noticed issue with lists which can be resolved using this css:
.markdown-body ol, .markdown-body ul {
padding-top: 0;
padding-bottom: 0;
padding-block-start: 2em;
}
result:

Quotation fix:
.markdown-body blockquote {
margin: 0 0 16px;
padding: 0 15px;
color: #777;
/* border-left: 4px solid #ddd; */
border-inline-start: 4px solid #ddd;
}
before:

after:

This is still in my mental queue to think about, but it may take a bit of time / some conversations with Design to work out exactly what we want here.
Let me know if I can help.
What is the update? What is preventing this PR to be finalized and merged?
I still need to work out an approach that handles edited markers and such, and then review that with Design. I haven't had time to do that yet.
I still need to work out an approach that handles edited markers and such, and then review that with Design. I haven't had time to do that yet.
May you share what specific issue is there? One (maybe me) might help
I have unfortunately failed to find the proper time to think about this... 😓 I'll send this back to the general queue in hopes that it might lead to new input here.
I have unfortunately failed to find the proper time to think about this... sweat I'll send this back to the general queue in hopes that it might lead to new input here.
May you please share what is there to think? Share the issue so that others might be able to offer some help.
@ahangarha its already in a thread above. https://github.com/matrix-org/matrix-react-sdk/pull/5453#discussion_r533035486
I'm obviously not familiar with RTL languages, but would it be awful to keep the (edited) bit on the right side of the message text? If that's fine, then we might be able to throw in some flexbox or similar CSS trickery to keep everything lined up (a problem would be multiline messages, but that might be solved with less flexbox and more DOM nesting)
@ahangarha its already in a thread above. #5453 (comment)
If this is the only remaining issue, I will share a solution. Just please list all the remaining issue.
@turt2live My understanding is ideally it would be on the left but if we could at least get the message oriented correctly and have the (edited) in the wrong spot that would still be much better than how it currently works.
At the moment, the app currently (without the change here) shows the "(edited)" label inline with the message text. The "easy" fix to apply RTL to messages also causes them to become a block elements, which moves the "(edited)" label to the next line. I believe the main options to move forward are either:
- Find a technical solution which preserves the inline placement of the edited label
- Work with Design team to change the placement of the edited label
As far as I see, it can be tweaked to follow bidi algorithm. So, if it is Latin, it remains on left and if gets translated to Persian (or other RTL languages) it moves to right. I think this is the right behavior. If you want to force it to follow the direction of the related text, it is doable but there should be significant change in the layout.
Yet to be frank, this is a minor issue as compared to the situation we (RTL people) face with. I would prefer to get the current improved version and then in next version improve this little minor issue.
Is there any build based on the current modifications so that I can check different scenarios?
Is there any build based on the current modifications so that I can check different scenarios?
See the deploy preview, you can find the latest link in the Checks section of the PR.
Hey! Just checked the deloyed preview, I think it might be better to align (edited) to the right side for edited RTL scripts. Usually, for designing in RTL it's preferred to mirror all components but I'm guessing that doesn't make any sense if we are using multi languages in the timeline.
Did you need feedback on anything else specifically?
See the deploy preview, you can find the latest link in the Checks section of the PR.
I check the preview. It looks fine in most cases. Still I should check more. But I found out one issue with code section.

It should not follow the the surrounding text direction. It should independently detect the direction of text in it.
Guys,
I have made these simple styles which nearly all issues with bidi support: https://userstyles.world/style/2159/element-bidi
As far as I see it is working perfectly. It was little issue if we have a mixed markdown content which can be managed in some way but doesn't have periority now.
I wonder why still we don't have this feature on element!

/* message text */
.mx_EventTile_body {
display: block;
text-align: start;
}
/*to apply on those messages having only plain text*/
.mx_EventTile_body:not(.markdown-body){
unicode-bidi: plaintext;
}
.markdown-body pre > code {
unicode-bidi: plaintext;
text-align: start;
display:block !important;
}
.mx_EventTile blockquote {
text-align: start;
unicode-bidi: plaintext;
}
/* fix lists view*/
.markdown-body ol, .markdown-body ul {
padding: 0;
padding-inline-start: 2em;
}
@ahangarha it looks like it has basically the same problem with the (edited) label though
@ahangarha it looks like it has basically the same problem with the
(edited)label though
I really don't understand why this is that much important to keep the 99.9% fix on hold.
See. I am using Element and I am who uses RTL/LTR both. If anyone is going to suffer it would be me and people like me. And I am fine with this. I don't see it even as a problem.
This is not a security issue! Just keep this to be fixed (if needed at all) in future. Don't hold this major improvement just for a tiny issue which is not even noticeable!
See. I am using Element and I am who uses RTL/LTR both. If anyone is going to suffer it would be me and people like me. And I am fine with this. I don't see it even as a problem.
But that's not true. If it only broke on RTL text it would probably be fine. But your CSS (as well as this PR) move the edited label to the wrong place on all messages, not just RTL.
See. I am using Element and I am who uses RTL/LTR both. If anyone is going to suffer it would be me and people like me. And I am fine with this. I don't see it even as a problem.
But that's not true. If it only broke on RTL text it would probably be fine. But your CSS (as well as this PR) move the edited label to the wrong place on all messages, not just RTL.
How much wrong is that place? It is just going to the next line. Is it a big issue? bigger than messing up with mixed RTL/LTR text? I don't think so. And frankly I think we should move that entirely out of that place but that is a different issue.
The fact is that Element has a big issue when it comes to RTL text. We can fix this big issue which would produce a little visual issue for only edited message. I think logic says lets fix the bigger problem now and fix the smaller later. We shouldn't let the smaller issue prevent us from fixing the bigger issue. Am I wrong?
I completly agree with @ahangarha in this case. Making Element usable in BiDi is more important than a minor visual issue. Anyway I think the current edited sign behaviour is already a bad UX decision and we should find another approach for indicating a message is edited.
As a RTL user, if this "edited" sign thing is the only reason that prevents me to use my language in messages properly, I really don't care about it.So I totally agree with @ahangarha and @danialbehzadi .
@ahangarha @danialbehzadi @SeedPuller Since a couple of days I was trying to edit styles to make UI compatible with RTL languages. Please check https://github.com/vector-im/element-web/issues/14520#issuecomment-1086704259 for a short video of UI in Hebrew (as UI is not available in languages of Arabic alphabet yet).
Thank you for your work but the issue is not to make overall layout RTL. We need it for sure but we need to show messages in correct direction regardless of the global language and direction.
در ۳ آوریل ۲۰۲۲ ۹:۵۴:۵۶ (GMT+03:00)، Suguru Hirahara @.> نوشت: @. @danialbehzadi @SeedPuller Since a couple of days I was trying to edit styles to make UI compatible with RTL languages. Please check https://github.com/vector-im/element-web/issues/14520#issuecomment-1086704259 for a short video of UI in Hebrew (as UI is not available in languages of Arabic alphabet yet).
-- Reply to this email directly or view it on GitHub: https://github.com/matrix-org/matrix-react-sdk/pull/5453#issuecomment-1086789693 You are receiving this because you were mentioned.
Message ID: @.***>