Open Bug 464436 Opened 17 years ago Updated 2 years ago

'Bidi Mail UI' functionality needed in Thunderbird for RTL locales - add direction buttons into composer

Categories

(Thunderbird :: Message Compose Window, defect)

Product:
Thunderbird
Component:
Message Compose Window
Type:
defect

Tracking

(Not tracked)

People

(Reporter: tomer, Unassigned, NeedInfo)

References

(
URL
)

Details

(Keywords: rtl, Whiteboard: [gs])

Attachments

(2 files)

Issues preventing integration of BiDi Mail UI functionality
3.27 KB, text/plain
Details
WIP using unicode-bidi
3.71 KB, patch
Details | Diff | Splinter Review
RTL locales are written from right to left and need controls to read and compose messages from right to left. Currently, Thunderbird don't have integrated controls, but an extension that can provide this functionality. We had the same situation with Firefox, and the extension code base was integrated into the browser for all locales. The code for Thunderbird is a bit larger, as there is a need to add direction buttons into composer.
Flags: wanted-thunderbird3?
We need this for two locales, which we hope to support in TB3, namely Hebrew (he) and Arabic (ar), the latter being added to all-locales only yesterday.
Flags: wanted-thunderbird3? → blocking-thunderbird3?
indeed, this bug is covered by bug 119857.
I agree. Bidirectional support is crucial in TB controls for RTL locales like Arabic, Hebrew, etc. Without it, mixed texts cannot be displayed properly.
We need this for Persian, in addition to Hebrew and Arabic, as well. And I don't think this should be locale specific. Users who read RTL should be able to benefit from this even if they are using the English version of Thunderbird.
As an average user I agree Ehsan Akhgari's comment that this should be available in the English version of Thunderbird. I am a native English speaker who frequently needs RTL. As such, I'd much rather use the English version and switch to RTL when needed, rather than download a locale specific version.
(In reply to comment #7) > As such, I'd much rather use the English version and > switch to RTL when needed, rather than download a locale specific version. For that reason I wrote in comment 0 that we would prefer to get the code integrated into Thunderbird (as it is with Firefox) rather than bundling the extension with RTL locales and requires the user to manually install the extension in case he is using any other UI language.
Please don't integrate the buttons without everything else (although you can do that if you like, the code is free after all). See also: https://www.mozdev.org/bugs/show_bug.cgi?id=20370 I also suggest marking this a dupe of 119857. Re Comment #8: Add addon installation suggestion to the installer, with recommendations being part of the installation bundle so you can tweak them. That might solve your problems. And if this should be available for everyone - it can be recommended to everyone :-)
Having this would be great, but I don't think we can afford to block tb3 on it. If people want to drive a patch forward, though, go ahead!
Flags: blocking-thunderbird3? → blocking-thunderbird3-
This is not really about TB 3 as opposed to TB 2 or 4.
Summary: Bidi UI needed in Thunderbird 3 for RTL locales → 'Bidi Mail UI' functionality needed in Thunderbird for RTL locales
Persian and Arabic-speaking users strongly need to fix this bug (RightToLeft).
Flags: wanted-thunderbird3?
Flags: wanted-thunderbird3? → wanted-thunderbird3+
It has been a major problem for me in Thunderbird. It is disappointing if it will not be fixed in the next version.
Well, you can install my extension, you know :-) The bigger problem AFAIAC is that there are some things my extension can't do, and it would take changes to the C++ code to do them. Like correcting charset and setting directions when printing messages. Also, some of what my extension does now is a bit of a hack, and should be really integrated into the code rather than just overlaying it.
I am not a Thunderbird developer, so sorry if this question seems funny to ask: is there anything preventing the merging of the extension code into Thunderbird core besides lack of time/resources? If not, then I'd be happy to take this as my first Thunderbird-specific bug. :-) (In reply to comment #16) > The bigger problem AFAIAC is that there are some things my extension can't do, > and it would take changes to the C++ code to do them. Like correcting charset > and setting directions when printing messages. Also, some of what my extension > does now is a bit of a hack, and should be really integrated into the code > rather than just overlaying it. Eyal: are there individual bugs for these issues? If not, would you mind filing them with detailed explanation? Mozilla is now very good at handling bidi, and I think some of those problems (like printing problems) can be solved with front-end changes which tell the back-end what direction/charset to use... Let's keep this bug focused on the uplift of the BiDi Mail UI extension.
(In reply to comment #17) > I am not a Thunderbird developer, so sorry if this question seems funny to > ask: is there anything preventing the merging of the extension code into > Thunderbird core besides lack of time/resources? No. As David Ascher correctly said in comment 10: "Having this would be great, but I don't think we can afford to block tb3 on it. If people want to drive a patch forward, though, go ahead!" > If not, then I'd be happy to take this as my first Thunderbird-specific > bug. :-) Great! I just assigned the bug to you ;)
Assignee: nobody → ehsan.akhgari
Status: NEW → ASSIGNED
(In reply to comment #17) Yes, there's a lot preventing the merging of the extension code into Thunderbird. In fact, most of it should never be merged. The thing is, that most of the code there are hacks to work around problems in the Mozilla code. Other parts are less hackish, but would still be done very differently if they were to be done within the C++ core (which they should). For example, setting the direction of text by analyzing paragraphs is something which is possibly relevant to text nodes, and should be done within the node, not by splitting it into different nodes. Or even if one decides it's better to split nodes, it shouldn't be by traversing the DOM ex-post-facto, but rather by constructing separate per-paragraph nodes to being with - in the MIME code. This and other issues need to be addressed before the main codebase can include the functionality of BiDi Mail UI. I therefore don't believe that Ehsan could take this on as his first experience working on the codebase. I therefore ask Ehsan or sipaq to consider un-assigning the bug. > Eyal: are there individual bugs for these issues? If not, would you mind > filing them with detailed explanation? Some of them exist, some do not. I'll try to file the remaining ones and list them here. email me if I don't do it within a week or so. > Mozilla is now very good at handling bidi I wouldn't say that. There's been a lot of imporvement but a lot of the code is still bidi-unaware, and even the main codebase has some parts which I think could use a rewrite (although I haven't been following the code too closely recently). > and I think some of those problems (like printing problems) can be solved > with front-end changes which tell the back-end what direction/charset to use... Unfortunately, this is also not really the case. However, working on improvements in this respect is easier, e.g. creating hooks for my extension to work on the DOM before printing: bug 423181. Finally, there's bug 326514, which would make people with Hebrew/Farsi/Arabic/etc locales aware my extension.
Flags: in-testsuite+
Flags: in-litmus+
Flags: in-testsuite+
Flags: in-litmus+
hi all i am Iranian and please excuse me for bad English i want rigth to left support for thunderbird 3 in email write and feed reader please support rtl language for thunderbird 3 and calendar add on goodbye
this is my dream! please add rtl support!
(In reply to comment #20) > hi all > i am Iranian and please excuse me for bad English > i want rigth to left support for thunderbird 3 in email write and feed reader > please support rtl language for thunderbird 3 and calendar add on > > goodbye hi you can email to "Falatooni@Gmail.com" to help you for your problem
Dear Hashemi, I'm not a developer of Thunderbird! but I suggest that until this feature is added into Thunderbird, install "BiDi" extension. This extension adds RTL button on editor of Thunderbird. Thanks.
We need it for writing emails in Persian. Regards, Moosavy
yeah, even gmail added such feature, why we can't have this feature in Thunderbird?
List of issues as promised. Like I said, some have gotten bugs opened for them here. Also please stop spamming this bug with "I want this too" messages.
hey Eyal, i think maybe i could help :) i saw your attachment i think many of problems you mentioned can be fixed via JS. I'm not pro in C++ but i can help in JS. so if there's something related to JS just notify me, if email is not enough & need to talk about it i can join you in mozilla irc network (In reply to comment #26) > Created an attachment (id=401710) [details] > Issues preventing integration of BiDi Mail UI functionality > > List of issues as promised. Like I said, some have gotten bugs opened for them > here. > > Also please stop spamming this bug with "I want this too" messages.
Would be great if someone could go through that list, filing bugs for the issues if they aren't filed already, and mark all the bugs as blocking this one.
FWIW, this one is still on my radar, but I don't expect to have enough time to work on this at least in a month. If someone else has free time and wants to step up, feel free to take this!
(In reply to comment #23) > Dear Hashemi, > I'm not a developer of Thunderbird! but I suggest that until this feature is > added into Thunderbird, install "BiDi" extension. > This extension adds RTL button on editor of Thunderbird. > Thanks. BiDi Mail UI 0.9.2 could not be installed because it is not compatible with Thunderbird 3.0.1.
(In reply to comment #29) > FWIW, this one is still on my radar, but I don't expect to have enough time to > work on this at least in a month. If someone else has free time and wants to > step up, feel free to take this! Ehsan, (and others) 1. what are the first steps needed? 2. does someone have a list of which items in attachment 401710 [details] still need bugs? or is it safe to assume that almost none of them have bugs? [1] 3. should this be the bug to which all others block? 4. is there a newsgroup or forum where some of the issues could be discussed so as to avoid causing lots of bugmail? (or have the issues been hashed out already?) [1] bugs labeled RTL/Bidi Thunderbird: http://bit.ly/gXiyeL Core/Toolkit: http://bit.ly/eIbTt8
(In reply to comment #31) Steps are: 1. Answer your question no. 2 2. File missing bugs 3. Spend, say, 2-12 man-months resolving all those bugs 4. Watch Eyal make his extension do nothing but add some XUL and glue 5. Integrate that into the main codebase For discussion, there used to be #bidi@irc.mozilla.org , but it's been empty recently. As for the lists of bugs, not all issues I mention are specifically BiDi-related. Finally, there may be an issue or two I've missed in addition to those in attachment 401710 [details], like the "can't work on messages sent to printing" which I mentioned earlier in the comments.
We need it for writing emails. Regards, Mohammadreza Noori
Not having this as a core feature, actually means that hundreds of millions of users can't get the most basic functionality from the application, unless they get a pre-built version for themselves. Please please add as a core feature...
As a heavy Thunderbird user I can say that the issues mentioned in attachment 401710 [details] are either nonexistent or so corner-case that I've never run into them. I receive email in every Hebrew charset imaginable and BiDiUi handles them such that I don't even know what the author used. Furthermore, these issues would exist either with or without the BiDiUi extension, so incorporating the BiDiUi code into core Thunderbird will not be introducing new bugs. It will only open a path to get those bugs properly filed and fixed.
Going through attachment 401710 [details] again, there is almost not a single valid issue in there. Some issues are completely non-actionable, such as: "The editor code is a total junkheap in general." Really, that is the reason to not implement BiDiUi? How noble. Other issues mentioned apply only to word-processor documents, not to plain text format or HTML, such as: "There's no handlable event for when the paragraph mode changes." The paragraph mode never changes in plain text, the concept doesn't even exist. Then that attachment complains about things that are completely irrelevant, such as: "Mozilla won't report which of the Shift keys got pressed" Mozilla does not need to support that. In Mozilla text direction is switched by Ctrl-Shift-X so there is no need to know which shift key was pressed. There is not a single valid blocker issue mentioned in that attachment. Go ahead and incorporate the BiDiUi code and we'll file bugs proper on the corner cases.
Considering the confusion between word-processor documents and plain text / HTML by the author of attachment 401710 [details], this document will be of use to understand the concepts of BiDi in both environments: http://dotancohen.com/howto/rtl_right_to_left.html
(In reply to Dotan Cohen from comments #36-#38) The issues I mentioned are mostly not such that a user would notice daily (or ever). But think of it this way: You have a house with a hole in the wall. Someone nails a plaster panel to the wall to hide it. Now you're suggesting we cement this panel to the wall, because when you look at it you don't see a problem. Well, that's not the way it should work: You need to fill the hole, or in some cases even rebuild the wall. Only about, oh, maybe 30-40% of the BiDi Mail UI code has any business being integrated into Thunderbird, and even that mostly needs to become C++ rather than Javascript. And it can't be integrated without filling the hole in the wall. Until that time, I've suggested that Thunderbird, when installing on systems with Hebrew or Arab locale, offer the new user to install BiDi Mail UI (and more generally offer relevant extensions): https://bugzilla.mozilla.org/show_bug.cgi?id=326514 Note also that there's me, developing the extension, and there are the Mozilla Messaging people and the core MailNews developers. You're addressing all of us together. The attachment is a list of issues _I_ wrote which in _my_ opinion must be resolved before integration can happen. Finally, I'm not sure if Bugzilla is the right place for this, but I will say that I would be interested in working on resolving (some/most) of these underlying issues, working for pay (I'm unemployed and this is a _lot_ of work). About specific issues you mentioned: - Sorry about the comment regarding the editor, it was written in frustration and isn't very constructive. We had many qualms with all of the behavior of existing code, the interfaces, and the features or lack thereof. - "In Mozilla text direction is switched by Ctrl-Shift-X" that's just a workaround we used. By the way, we now have Ctrl-Shift working, but it's the same as Ctrl-Shift-X , with no distinguishing between RShift and LShift.
Thanks for the detailed reply, Eyal. You know that we appreciate your work! > The issues I mentioned are mostly not such that a user would > notice daily (or ever). That right there makes them a non-issue for users. Nobody wants a spaghetti-code mess Netscape Navigator 4 style. However, waiting for the "perfect code" is like waiting for the perfect woman. It will never come. So we settle down with something that meets our needs and take it from there. The issues that turn out to be big issues we fix. The rest we live with. At least there is _something_ to live with. (Don't let my wife read that. Just in case: Ety, you're perfect! If you were code then Knuth wrote you.) > But think of it this way: You have a house with a hole in the wall. > Someone nails a plaster panel to the wall to hide it. Now you're > suggesting we cement this panel to the wall, because when you look > at it you don't see a problem. Well, that's not the way it should > work: You need to fill the hole, or in some cases even rebuild the > wall. That's a decent analogy, I'll try to run with it. This hole in the wall is letting rain in, and it is ruining your possessions. We don't have the resources to tear down the wall and build a new one. That might even entail tearing down the whole house. So yes, we do cement this panel to the wall. It takes care of the problem. Who cares if there is a hole in the wall behind the cement if it has no effect on the user, or the stability / performance / maintainability of the code? > Only about, oh, maybe 30-40% of the BiDi Mail UI code has any business > being integrated into Thunderbird, and even that mostly needs to become > C++ rather than Javascript. And it can't be integrated without filling > the hole in the wall. Let's look at three scenarios: 1) Convert to C++ and fix the hole in the wall. Do you or Mozilla have the resources to do that? 2) Leave it as Javascript and put it in Thunderbird. Thunderbird spend most of it's time waiting for the user, not running this Javascript in some tight loop. There is no performance penalty. There are no regressions compared to the current situation, even for non-BiDi users. The code can even be refactored at a later date. 3) Do nothing. That's all the disadvantages of scenario 1 with all the disadvantages of scenario 2. No benefit at all. > Until that time, I've suggested that Thunderbird, when installing > on systems with Hebrew or Arab locale, offer the new user to > install BiDi Mail UI (and more generally offer relevant extensions) And what happens when Thunderbird jumps a version number and the user's extensions are incompatible and disabled. That's fine for a Facebook-integrating addon or an ad blocker. That is not fine for a critical piece of code that changes the behaviour of the application and disables essential functions. Your code is important, Eyal, and people rely on it. Was it Larry Wall who said that programmers must exhibit hubris? This is why! > Note also that there's me, developing the extension, and there > are the Mozilla Messaging people and the core MailNews developers. > You're addressing all of us together. The attachment is a list of > issues _I_ wrote which in _my_ opinion must be resolved before > integration can happen. Then do the Mozilla Messaging people object to including the code in core Thunderbird? How about the MailNews developers? Are they CCed here? I'll make an effort to talk to the right people if I'll know who they are. > Finally, I'm not sure if Bugzilla is the right place for this, but > I will say that I would be interested in working on resolving > (some/most) of these underlying issues, working for pay (I'm > unemployed and this is a _lot_ of work). I think that it is appropriate and it is relevant. I'll chip in $20 USD via PayPal or right to your bank account seeing how we're in the same small patch of sunlight. If you're ever in Be'er Sheva then there's a cold beer waiting for you too. That money is not payment for your development time (that amount would be an insult if it were) but rather a donation considering your contribution to the open source community. If 10 people here were to donate such I think that you'd make out rather well. Feel free to mention this donation and my proposal to other people subscribed to this and other relevant bugs. Decide for yourself if the feedback is worth the effort. Alternatively, if you're willing to mentor I'll take it upon myself to learn C++ and the Mozilla internals. I'll have a lot to learn but I'll make the effort with a bit of hand holding. I've yet to develop so much as a Mozilla extension but I'll try. In any case, I hope that you realize that any frustration that people express here or on the other bugs is frustration with Thunderbird's lack of RTL support. Your extension and your contributions are very much appreciated and welcomed, even if some people (possibly myself included) direct their frustration in unconstructive or ambiguous ways.
Dotan, some of the issues we're talking about are quite deep and fundamental. Very few, if any, of them are such that I could mentor anyone so as to be able to resolve. Solving the majority of them would take, I dunno, maybe a few months for a reasonably experienced Mozilla developer (and significantly more for me). Work the MIME library is a gargantuan undertaking, as is the editor (although there's nothing really critical there). So, this is not about a one or ten small donations, this is serious work, to be taken instead of a job somewhere else, for quite a while, by someone. I realize your frustration, there are several issues with Thunderbird I've been waiting for years to see resolved and nobody's working on them. See: https://wiki.mozilla.org/Talk:Thunderbird:Future_of_Thunderbird by the way, at least one of these issues has been partially resolved in a way which requires an extension to make work: https://addons.mozilla.org/en-US/thunderbird/addon/filtaquilla/ And that might well merit integration well before any of my code. Also, there is certainly a performance penalty with my extension, and it's quite steep. You would definitely should not have my charset mis-decoding and direction detection code running by default. (Will keep in mind the beer invitation in case I'm down in Be'er-Sheva) Finally, your website seems to be down.
As for reading plain text emails, I think that <pre dir=auto> (see bug 548206 for more information). For regular messages I think it should be safe enough to stick with the alignment set by the author, and add a feature to change the direction manually like how we do it in Firefox – "Switch page direction" configured by the preference bidi.browser.ui and hidden by default for most users. As for composing messages, we might be able to implement the composer tricks introduced by bidiui addon. If people will need more advanced direction guessing algorithms, I think that there is a room for an addon, but basic and complete support should by integrated into Thunderbird core.
> Dotan, some of the issues we're talking about are quite deep and fundamental. Very few, if any, of > them are such that I could mentor anyone so as to be able to resolve. Solving the majority of them > would take, I dunno, maybe a few months for a reasonably experienced Mozilla developer (and > significantly more for me). Work the MIME library is a gargantuan undertaking, as is the editor > (although there's nothing really critical there). So, this is not about a one or ten small donations, > this is serious work, to be taken instead of a job somewhere else, for quite a while, by someone. I see. Well, I tried! > I realize your frustration, there are several issues with Thunderbird I've been waiting for years > to see resolved and nobody's working on them. See: > https://wiki.mozilla.org/Talk:Thunderbird:Future_of_Thunderbird I hope that there exist actionable bugs filed for those features. > Also, there is certainly a performance penalty with my extension, and it's quite steep. You would > definitely should not have my charset mis-decoding and direction detection code running by default. Steep as in tens of miliseconds? I have tested BiDiUi in new profiles and in profiles with almost a gigabyte of mail and attachments: no noticeable difference in performance. This is on Ubuntu running on hardware with a modern AMD processor, and in Windows in Virtualbox on the same physical hardware. > (Will keep in mind the beer invitation in case I'm down in Be'er-Sheva) Very good! 054-7881700 > Finally, your website seems to be down. Let me guess, Hot infrastructure without a dialer? Could you mail me the output of running "mtr dotancohen.com" for a minute or two? I need Hot to fix this, they limit the amount of hops a connection can take, and I need the mtr output to convince them. Thanks.
> As for reading plain text emails, I think that <pre dir=auto> (see bug 548206 for > more information). Bug 548206 specifically mentions using the BiDiUi algorithm for the dir=auto feature. > For regular messages I think it should be safe enough to stick with the alignment set > by the author, and add a feature to change the direction manually like how we do it > in Firefox – "Switch page direction" configured by the preference bidi.browser.ui and > hidden by default for most users. Regular messages (non-HTML messages) do not support author-set alignment at the document level. In theory one could enter an RLE [1] or LRE [2] character into the text, but few users know to do that. I'm a heavy RTL user, and I'm the only one that I know of that uses those characters. > As for composing messages, we might be able to implement the composer tricks introduced > by bidiui addon. Specifically in composing the BiDiUi extension does not help me, I must Ctrl-Shift-X in RTL mails. And in those mails I do add an RLE to the beginning of the subject line and the beginning of the mail text so that the recipient will have it displayed correctly no matter what his settings are. > If people will need more advanced direction guessing algorithms, I think that there is a > room for an addon, but basic and complete support should by integrated into Thunderbird core. Agreed. [1] http://www.fileformat.info/info/unicode/char/202b/index.htm [2] http://www.fileformat.info/info/unicode/char/202a/index.htm
(In reply to comment #42) > As for composing messages, we might be able to implement the composer tricks > introduced by bidiui addon. FWIW, we could also use dir=auto as a basic strategy when composing email too. Then, we can get the computed direction value of the text field for things like HTML-encoding a plaintext mail, etc.
Here's a simple WIP that uses unicode-bidi to autodetect the directionality in the message composer and for the message body display. Since I don't speak any RTL language, I can't properly test this. Feedback welcome.
Flags: needinfo?(eyalroz)
Attachment #8642022 - Flags: feedback?(eyalroz)
Attachment #8642022 - Flags: feedback?
(In reply to aleth [:aleth] from comment #47) > Here's a simple WIP that uses unicode-bidi to autodetect the directionality > in the message composer and for the message body display. Having the message direction set by unicode-bidi:-moz-plaintext, as well as dir=auto will cause the message direction to change by its content (and without smart heuristics), the user will get the impression that the message has direction set, but the message will be sent without any indication on which paragraphs are right-to-left. If the recipient mail agent has similar implementation, the message may be displayed well, but we can't make sure it will be ever supported be most mail agents. On the other hand, if before the message is sent each RTL paragraph will get surrounded by RLE…PDF and every LTR paragraph will get surrounded by LRE…PDF, it could be good enough indication of the paragraph direction, and mail agents that doesn't implement dir=auto code but has good bidirectional support won't be right-aligned but message direction will be preserved. Having that said, I think that we'd need a way to set paragraph direction manually, by a keyboard shortcut and a toolbar button. If implementing dir=auto, we could get its help by the following pseudo code: ChangeParagraphToRTL(): if paragraph doesn't starts with LRE and doesn't ends with PDF: paragraph = "[RLE]" + paragraph + "[PDF]" else if paragaph starts with LRE and ends with PDF: paragraph[0] = "[RLE]" And similar code for ChangeParagraphToLTR() and SwitchParagraphDirection().
Attachment #8642022 - Flags: feedback? → feedback?(tomer.moz.bugs)
Comment on attachment 8642022 [details] [diff] [review] WIP using unicode-bidi I'll add a few points to what Tomer said. 1. The heuristic with auto direction is much more simplistic than what my extension provides, and this will cause quite the annoyance if the user can't override it manually - especially when composing a message. 2. We need to separate the feedback on this patch as regarding message _display_ and message _composition_. For composition, it is problematic to apply direction auto to the message being composed, since as Tomer said - this doesn't carry over to the recipient. It's important that "what you see is what they get" (well, in some respects, anyway). Now, one could make sure direction: auto is added to the outgoing message, but I don't believe this is a good choice; and no mail client or document processor does anything like this. For composition, you need UI for properly setting direction yourself, per message and per paragraph/block element, with this setting being 'imprinted' into the HTML. An exception is plain-text email, in which you only set the overall direction for display purposes - just like you do in a text box on a website. But in that case, 'auto' is again not useful, since the user usually expects to see the whole message RTLed or LTRed - again, like in website textboxes. 3. Direction should be set for different block elements within a message; and for a text message, for different paragraphs, meaning we need to wrap #text DOM nodes with block elements. That's obviously not addressed with the stylesheet (although this in itself is not a reason to avoid it - like points 1 and 2 above). 4. The best thing AFAIAC would be to integrate functionality from my extension into Thunderbird and even into the layout engine, so that you can say something like 'direction: -moz-fancy-auto' and get my complex heuristic, plus Thunderbird itself will break up text messages into paragraph-level block elements for direction setting. A pref will control whether the default is no setting, auto, or fancy-auto. The UI will have relevant buttons/menubuttons. etc. This should also allow direction setting in messages going to print. I've written about this in earlier comments.
Flags: needinfo?(eyalroz)
Attachment #8642022 - Flags: feedback?(eyalroz)
(In reply to Tomer Cohen :tomer from comment #48) Tomer, Eyal, thanks for your detailed feedback! I guess what I was hoping was that this bug, which has been sitting untouched for years, could be broken up into a few separate steps, each of which would improve things a bit. Let's not have the perfect be the enemy of the good. (As you've pointed out in earlier comments, a perfect solution would likely require manpower which is not available.) In this spirit, my impression from your feedback is that 1) adding dir:auto/unicode-bidi, while not perfect, could be a good thing for message _display_ (assuming RTL/LTR flags, if present in the email, override it). Should I go ahead with this? 2) adding dir:auto/unicode-bidi won't help in message composition, unless maybe it were possible to read out the RTL/LTR assignment chosen by the algorithm before sending and then annotating the email with these flags. I believe that's currently not possible, but I can investigate. 3) For message _composition_, the minimum solution would be to add a RTL/LTR button to the composer UI, that inserts tags. It sounds like the Bidi addon already has code for this that could be ported. Would this make sense? > 4. The best thing AFAIAC would be to integrate functionality from my > extension into Thunderbird and even into the layout engine, so that you can > say something like 'direction: -moz-fancy-auto' and get my complex > heuristic, plus Thunderbird itself will break up text messages into > paragraph-level block elements for direction setting. If you think dir:auto currently has bugs/things it could do better using your heuristics, I would suggest talking to e.g. smontagu, who might be quite interested in improving things! I don't think there'll be any support for adding a separate -moz-fancy-auto to gecko though. Auto should just work...
Note that there exists a standards-compliant and well-support way to have plain-text RTL paragraphs display properly in all email clients. There exists an character called the RLE (Right-to-Left Embedding, Unicode symbol U+202B) which tells the client to treat the next paragraph as RTL. I add an RLE character to the beginning of all my RTL paragraphs, and all user complaints have vanished. It seems to be supported in Outlook, Gmail, Thunderbird, and all the other common email clients and web sites. As a bonus, the Thunderbird (and all others) compose window displays the RTL paragraph properly when using this character. That is, punctuation appears properly on the left end of the paragraph.
Attachment #8642022 - Flags: feedback?(tomer.moz.bugs)
Status: ASSIGNED → NEW
See Also: → 361528
This add-on still reverses the display direction of previously sent Thunderbird messages. Seven months ago the author of this add-on promised us a Thunderbird-compatible version. He has yet to deliver. The add-on is not even at version 1.0 yet.
This is the one of the buggiest add-ons ever written for Thunderbird. It keeps reversing the display direction of already sent messages. If you set the Default Direction as Left to Right, and check Always Reply in default direction, it still sets replies in the Right to Left direction. If you write a bilingual English and Hebrew message, you have to manipulate the options and reformat the body of your message many times before you can send your message. If you check Start composing new HTML messages in paragraph mode, it starts in Body mode. The author has repeatedly promised a Version 1.0 but is still at Version 0.9.8 many years after releasing his add-on. He should either work hard to fix all the bugs or remove this add-on from the Thunderbird add-on website.
And what should users like me who depend on this add-on do?! If you don't want it, simply remove it from your own thunderbird. He has done something that Thunderbird should have done years ago, and there is no better alternative, so why you are so rude?
I found a nice workaround! The signature can be an html code. So i use: <p dir="rtl">שלום</p> as a signature. when you write a new email, simply overwrite the word שלום. when replying you'll need to copy the whole signature (including the "--" part) from the bottom to the top and work from there. could someone make this into a button in the interface? it's better to have an ugly solution than to wait 9 years for a one.
With the legacy add-ons api deprecation of Firefox, it might affect legacy Thunderbird extensions sooner or later, so unless the add-on author will convert the add-on the WebExtension, it might be impossible to use Tb for compositing RTL messages.
Followers of this bug should be aware that Mozilla is not "deprecating a legacy API", it's removing a core functionality - extension support. If you look at the FAQ: https://wiki.mozilla.org/WebExtensions/FAQ You'll read "In the legacy technologies (extensions [snip]) developers had access to almost everything in Firefox. This causes many problems..." Extensions are useful because the application is instrumented for their use; because they 'have access" to things. No access, no extensions basically. Some limited functionality, probably mostly web-browsing-specific, will remain. I'm not aware of significant TB extensions working with WebExtensions (although I could be wrong, I'm not following very closely). So, rephrasing what Tomer has written: Since Mozilla is dropping extension support, it may well become impossible to use TB for composing RTL messages. I know Thunderbird has a governance council structure which is thinking about what to do with the whole project in the long-run, but I don't have a picture of what's going to happen over the next year or so.
Assignee: ehsan → nobody

The moment has come it seems. TB 78 doesn't support BiDi Mail UI.

@eladhen: Actually, it's somewhat better than I'd assumed 3 years ago.

My extension last without any changes until v60.x . Then, last year, I was able to adapt my extension with limited changes to TB 60-68.x - buying us another year. Now, support for XUL extension is finally dropped. But - there's a "loophole" called "Web Experiments", which lets "Web Extensions" have privileged access which until today was just the usual way extensions worked. It's possible, perhaps even probable, that I will be able to "thread the needle" here and get everything working again. Still, I can't make guarantees.

The URL from the previous message was wrong. Should be:
https://github.com/eyalroz/bidimailui/

See Also: → 119857
Severity: normal → S3
Summary: 'Bidi Mail UI' functionality needed in Thunderbird for RTL locales → 'Bidi Mail UI' functionality needed in Thunderbird for RTL locales - add direction buttons into composer

zaphod, hedayat,

Do you still see this bug?

Flags: needinfo?(zaphod_Bi)
Flags: needinfo?(hedayat.fwd+mz)
See Also: → https://support.mozilla.org/en-US/questions/1419200

Yes. It is actually a feature request rather than a bug report, so its less likely to be automatically fixed as part of other changes (well, it might be partially fixed if the editor gains support for automatic direction detection; or support changing the direction using a combination like left/right ctrl+shift). So, it most likely should be fixed intentionally!

Flags: needinfo?(hedayat.fwd+mz)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: