Last Comment Bug 107884 - Introduce editable templates for reply header strings
: Introduce editable templates for reply header strings
Status: NEW
[patchlove][has draft patch]
:
Product: MailNews Core
Classification: Components
Component: Localization (show other bugs)
: Trunk
: All All
: -- normal with 35 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
: 78101 212092 227575 229084 302142 787900 (view as bug list)
Depends on: 171822 694514 733258
Blocks: 13818 140377 171047 218258 218926 275195 450638 460646 479626 218558 666923
  Show dependency treegraph
 
Reported: 2001-10-31 17:30 PST by nhottanscp
Modified: 2016-07-21 14:14 PDT (History)
56 users (show)
dmose: blocking‑thunderbird3-
dmose: wanted‑thunderbird3+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
UI to select reply header type with editable strings. (1.86 KB, text/html)
2001-11-15 13:17 PST, nhottanscp
no flags Details
added language selection and a edit field for forward inline. (3.66 KB, text/html)
2001-11-20 12:13 PST, nhottanscp
no flags Details
Added fields for forward inline (subject, date, from, to), I don't think they have the ordering issue. (4.14 KB, text/html)
2001-12-06 10:44 PST, nhottanscp
no flags Details
a patch (15.51 KB, patch)
2008-12-12 19:42 PST, Makoto Kato [:m_kato]
no flags Details | Diff | Splinter Review
patch v2 (17.67 KB, patch)
2008-12-31 00:42 PST, Makoto Kato [:m_kato]
no flags Details | Diff | Splinter Review
patch v3 (18.91 KB, patch)
2009-04-04 08:00 PDT, Makoto Kato [:m_kato]
no flags Details | Diff | Splinter Review

Description nhottanscp 2001-10-31 17:30:08 PST
Reply header string like " wrote:" are now editable (see bug 70842).
Now need UI for this. This is not going to be simple. In addition to provide
editable fields, it also has to take care word order.
Comment 1 nhottanscp 2001-10-31 17:32:10 PST
Reassign to nhotta, cc to ducarroz, jglick, momoi, putterman.
Comment 2 scottputterman 2001-10-31 17:41:48 PST
My personal opinion is that I would keep this as a hidden pref.
Comment 3 jglick 2001-11-01 11:53:45 PST
Agree. Not sure I see the need for a visible pref.
Comment 4 nhottanscp 2001-11-01 13:11:59 PST
putterman, glick,
Do you think the user usually not want to edit those strings?
Comment 5 scottputterman 2001-11-01 14:24:47 PST
My guess is that the average person wouldn't want to and a poweruser could edit
the hidden pref.  have we allowed this customization in the past?
Comment 6 Katsuhiko Momoi 2001-11-01 14:29:44 PST
I think this is one of those nice personal touch feature
that will please even average users. I think being able
to change the way "XXX wrote:" in a way that matches your 
personal taste would be a good addition to a set of
personalization features -- if it is done correctly, that
is. So my vote is for a good usable UI.
Comment 7 nhottanscp 2001-11-01 14:41:07 PST
We have not provided editable reply headers in the past.
One thing not easy is editing the strings because the strings should be in UTF-8.
Comment 8 Michele Carlson 2001-11-13 15:39:45 PST
removing l12y
Comment 9 nhottanscp 2001-11-15 13:17:02 PST
Created attachment 57973 [details]
UI to select reply header type with editable strings.
Comment 10 nhottanscp 2001-11-15 13:28:24 PST
The attached UI provides editable strings for reply headers and selection of
header types (e.g., "auther wrote:" or "On date, auther wrote:").
I have not figured out how to provide the ordering control of "%s wrote" by UI
without bother the user with "%s".
Also I need help for wording.
Comment 11 jglick 2001-11-15 16:46:38 PST
Where would this ui go? Global Mail prefs? Per Account settings? (global 
probably the best option)
Comment 12 nhottanscp 2001-11-15 18:09:02 PST
I agree, I don't think we need per account settings for the strings.
Comment 13 nhottanscp 2001-11-20 12:13:41 PST
Created attachment 58567 [details]
added language selection and a edit field for forward inline.
Comment 14 nhottanscp 2001-11-20 13:07:02 PST
I added a language selection which will affect the date format in the reply
header. It could be also used to extract the default strings from .property files.
For forward inline, I just put a field for "--- Original Message ---". Other
fields ("Subject:", "Date", "From:", "To:") can be added but those are based on
the original message header. I think they can stay as English.
Comment 15 Holger Metzger 2001-12-05 11:18:47 PST
This is more or less a poweruser feature. An UI setting so that average users
can use it is very difficult to accomplish, especially for people of different
languages, different word orders.
In my opinion Xnews found quite a good solution, here's a screenshot:
http://www.hmetzger.de/xnews.png

- Holger
Comment 16 Dan Mosedale (:dmose) 2001-12-05 13:19:50 PST
It seems like it would be useful to have this as a per-account setting.  After
all, folks are not unlikely to read and reply to different language newsgroups
via separate news servers.  No?
Comment 17 Katsuhiko Momoi 2001-12-05 13:49:39 PST
> It seems like it would be useful to have this as a per-account setting.  After
> all, folks are not unlikely to read and reply to different language newsgroups
> via separate news servers.  No?

Yes. I do it all the time. Generally our experience up to now shows that 
those working in international business, academe, research type of institions
use mail/news messages in different languages. The number of bilingual (and
multilingual) people are increasing (not decreasing) as the global business
and communication increase. 
For this reason I would like to see a bit more flexibility than per account
settings.
Comment 18 Alec Flett 2001-12-05 14:34:18 PST
you should use localized pref strings, which means the default value comes out
of a  string bundle. (in fact, that's how the original bug should have been fixed!)
Comment 19 nhottanscp 2001-12-05 14:45:15 PST
The design is to get the default from non localized pref then allow the user to
select localized strings from bundles if the user really wants to change. That
is avoiding cases where reply header strings does not match the message body's
charset.
Comment 20 nhottanscp 2001-12-05 15:02:09 PST
This is not going to make 0.9.7, move to 0.9.9.

About the comment #15 about Xnews example, can we assume that the users who want
this feature can also understand "%s"?


Comment 21 Navneet Karnani 2001-12-05 21:36:35 PST
I like the approach where there are defined templates based on the locale. So,
having a drop down with 3 or four options would be better. 

But, as a first implementation, this is a good approach. The user can be assumed
to know the %s , %d , %to , %from , %cc, %subject , %newline . The next step
would be to allow a "Reset to default" button for people who mess up with the
string but don't know how to get back. Another good thing might be a string
builder which allows string ids to be inserted in a text field as the user types
his required characters. 
Comment 22 neil@parkwaycc.co.uk 2001-12-06 02:59:32 PST
mpt will probably scream at me for this, but how about a drop-down list that
displays (localized) Sender, Date, To, From, CC, Subject and Newline, but
actually inserts %s, %d, %to, %from, %cc, %subject or %newline (the insert
should replace the selection as if pasted in) when the entry is selected from
the list?
Comment 23 nhottanscp 2001-12-06 10:10:22 PST
From comment #21
>Another good thing might be a string
>builder which allows string ids to be inserted in a text field as the user types
>his required characters. 
This I don't understand. Any reason of showing string ids to the user?
Comment 24 nhottanscp 2001-12-06 10:19:15 PST
In proposed attachment (id=58567), the selecting from 'Language' automatically
inserts default values for that language. It is possible to add a button to
reset to the default (the one in mailnews.js), or we can add 'restore default'
in the 'Language' selection.
Comment 25 scottputterman 2001-12-06 10:40:31 PST
Can you post a screenshot of what the preference panel is going to look like? 
Is everything in the 2nd attachment going to be in it?  I hope I'm
misunderstanding this, but it seems like a lot of UI for something that's pretty
minor.

I still think this is better left hidden.  Jennifer, any thoughts?
Comment 26 nhottanscp 2001-12-06 10:44:26 PST
Created attachment 60663 [details]
Added fields for forward inline (subject, date, from, to), I don't think they have the ordering issue.
Comment 27 scottputterman 2001-12-06 10:49:01 PST
Each successive attachment makes me want to hide this pref even more!
Comment 28 Alec Flett 2001-12-06 10:53:39 PST
Personally, I think this interfaces is WAY over-engineered. this is definitely
an Advanced user feature, and its never going to be an "easy" interface to use,
not to mention this is going to be a headache for localizers because they have
to figure out how the UI works in order to localize it.

Personally I think we should just have some a text box and some text that says:
"Enter the header line. use %s for Subject, %a for Author, ..." and explain a
few others...
Comment 29 nhottanscp 2001-12-06 10:54:19 PST
Scott, I didn't see your comment before I attached the last one.
Some people mentioned the setting to be a part of the account set up.
Do you mean hiding it by adding an indirection like 'more...' button or make it
backend only?
Comment 30 jglick 2001-12-06 10:55:13 PST
I agree this is getting pretty complicated. If you want it to be visible, you
should keep it pretty basic/limited, and leave it as a Global pref grouped with
the other Reply and Forward global prefs. Otherwise, make it a hidden pref.
Comment 31 scottputterman 2001-12-06 10:58:41 PST
As Alec said, I think this is an advanced feature.  The UI being presented is
overkill and is confusing.  I personally don't think this needs to be exposed in
the UI.  If others feel strongly enough about this that it's determined it will
be exposed, then I would hope we can get this down to one edit field and some
explanatory text as Alec suggested. 
Comment 32 Jonas Jørgensen 2001-12-06 12:46:12 PST
IMHO it would be nice to be able to change this not just globally, not just per
account, but per newsgroup. (Ouch! Don't hit me!)
Comment 33 Katsuhiko Momoi 2001-12-06 13:54:40 PST
Can we do this using a template similar to AOL Instant
Msgr's Away message custom dialog? Let the user who
want to use this feature change the word order as needed.
We don't have to provide a template for each language. 
It's one field with exaplanation. 
Comment 34 nhottanscp 2001-12-07 14:38:42 PST
I am fine with doing as one field.
* Can we share the field for both reply and forward inline?
* Do we need a way to set a locale which is needed for formatting dates?
Comment 35 Katsuhiko Momoi 2001-12-07 18:04:10 PST
> * Can we share the field for both reply and forward inline?

How will this work? Presumably, the reply header will have a
template like:

In a message dated %Date, %S wrote:

while the forward inline will simply have:

-------- Original Message --------

> * Do we need a way to set a locale which is needed for formatting dates?

If we allow for a variable like %Date as in the above sample
template, can we make it sensitive to the date/time 
setting of the OS and simply pick up that value? This way
we can **avoid** having to set up something like:

At %hour %min on $date, %S wrote:

Comment 36 nhottanscp 2001-12-10 10:46:44 PST
Okay, we may assume that the user who edits the header also wants the date to be
formatted using default locale.
About reply and forward inline, if they need different strings then UI need to
have separate text fields or a way to switch a state.
Comment 37 danielmc 2001-12-11 07:28:16 PST
Nominating.
Comment 38 Katsuhiko Momoi 2001-12-11 07:34:38 PST
> Okay, we may assume that the user who edits the header also wants 
> the date to be formatted using default locale.

This applies to only the format. Is that correct? If the user has not
localized the header, we would not want %Date to display in the language
of the system locale, e.g. I modify the order of elements under
Japanese Window but don't change from English into Japanese.  In this
case, I don't want %Date to be displayed in Japanese. 

Comment 39 nhottanscp 2001-12-11 10:09:16 PST
I misunderstood the comment #35. But how the user can know the usage of %Date?
Comment 40 Katsuhiko Momoi 2001-12-12 14:53:55 PST
> I misunderstood the comment #35. But how the user can know the usage of > %Date?

How about providing basic bilingual capability in the template
including date?

1. If there is no specific action by the user, we assume
that %Date would be in the locale of the OS. (I thought about
using the locale of the Mozilla build but that would complicate
it too much.)

2. The user can change the locale of "%Date" to "%Date-en". This
will display the date in English but will use the format the user
chose in the OS.

That's it. So the idea is to offer 2-way option. The Date in
the OS-locale language/format or the date in English (en) 
language/OS-format. The latter option is always available
regardless of the OS locales (hopefully such a facility is
available for all 3 platforms).

Comment 41 nhottanscp 2001-12-12 16:43:09 PST
I prefer ASCII date to be a default, because locale date may not be readable if
the recipient does not have the same locale.
Comment 42 Katsuhiko Momoi 2001-12-12 18:05:49 PST
> I prefer ASCII date to be a default, because locale date 
> may not be readable if the recipient does not have the 
> same locale.

OK. I don't mind that. In that case, something like
%Date (for EN) -- default//display format will follow the
  settng in OS. 
%Date-OS (for the language of the OS)//display format will follow the
  settng in OS.

I don't think we should use LANG tags. That complicates it --
in that users will assume that %Date-ja, %Date-ko, etc.
arepossible.

Comment 43 nhottanscp 2001-12-13 10:15:38 PST
Summarizing the proposals so far, need three items.

1) static text to explain about the fields (need proposal).

2) text field1 (for reply),
default value: "On %Date %s wrote:"

3) text field2 (for forward inline),
default value: "-------- Original Message --------"

For forward inline, should those labels (Subject, Date...) be editable?

Subject: [Bug 107884] Pref UI for editable reply header strings
Date: Wed, 12 Dec 2001 18:05:50 -0800 (PST)
From: bugzilla-daemon@mozilla.org
To: nhotta@netscape.com
Comment 44 Alec Flett 2001-12-13 11:10:27 PST
minor nit: if we're going to have %Date, we should have %Author, not %s.

I think it will be a major headache to make %Date editable.. what if I enter
%Tiempo in my string, and then switch languages - suddenly I'm no longer
matching against %Tiempo, because its looking for %Date. How about just single
letters, so we don't have to justify the names?

%D for date
%A for author
%R for recipient(s)?
%N for newsgroup?

Comment 45 Katsuhiko Momoi 2001-12-13 11:36:07 PST
alecf, %Date was meant to be a name which stands for a variable
for the OS date -- I am using it just for discussion. I have no 
objection to what you're proposing. Single letter variables are
fine.

nhotta.

> For forward inline, should those labels (Subject, Date...) be 
> editable?

I vote against this. We should not touch the original mmessage
including the language of the headers. It is possible that
some mailers will display well-formatted RFC (2)822 headers in
the language of the client. That is wonderful if that can be
done but it is beyond what we should be doing for forwarding.
Comment 46 nhottanscp 2001-12-13 11:57:19 PST
How about %D for ASCII date %d for OS locale date?
What case is %R or %N used?
Comment 47 Katsuhiko Momoi 2001-12-13 12:31:04 PST
> How about %D for ASCII date %d for OS locale date?

Great.

> What case is %R or %N used?

One example of a full usage is something like the 
following:

In a message dated %D addressed to %R in %N, %A said:

Comment 48 Matthew Paul Thomas 2001-12-13 22:19:47 PST
I think this bug is a dup.

> mpt will probably scream at me for this, but how about a drop-down list

Funny, that's just what I was going to suggest. :-)

| Begin quoted text with:______
| [<name>_wrote:_______________] [V]______________
|                                | Author's Name  |
|                                | E-mail Address |
|                                | Subject        |
|                                | Date           |
|                                | Time           |
|                                | Message ID     |
|                                | Newsgroup      |
|                                |----------------|
|                                | < character    |
|                                | > character    |
|                                 """"""""""""""""

Please don't use %whatever -- that's the sort of geekiness a user shouldn't be 
exposed to. (<http://www.hmetzger.de/xnews.png> is reminiscent of
<http://iarchitect.com/controls.htm#CONTROLS21>.) <whatever> would be much 
preferable. (Alas, you would still have to descend into `&lt;' and `&gt;' if 
the user actually wanted to insert a < or > character, but hopefully more 
people know what `&lt;' means than know what `\%' means.)

Bonus points if you can come up with a special text field where `<name>',
`<address>' etc are self-contained and colored characters which can be deleted 
with a single Backspace keypress etc.

For mail accounts, I'd prefer the `Newsgroup' item to be disabled, not hidden.
Comment 49 Katsuhiko Momoi 2001-12-13 22:35:34 PST
> I think this bug is a dup.

Duplicate of which bug?

>> mpt will probably scream at me for this, but how about a drop-down list

> Funny, that's just what I was going to suggest. :-)

(illustration of the UI)

Can you explain how this UI handles word order differences
among different languages in how the selected
items are ordered?

Comment 50 Katsuhiko Momoi 2001-12-13 22:52:05 PST
> Can you explain how this UI handles word order differences
> among different languages in how the selected
> items are ordered

As I understand the requirements of this UI (see Bug 70842), 
there are 2 main items:

1. Items should be localizable by user, i.e. the user should
   be able to keep the English string or use the ones
   for the language of his choice by writing in these
   strings.
2. Word order of selected items should be re-arrangeable
   according to the convention of the language the user
   chooses to express this string. 

So my question to mpt's UI would be how these requirements
are satisfied. In a single editable string (as a
provided example in the UI) such as the one suggested above and
quoted below again, 

"In a message dated %D addressed to %R in %N, %A said:"

this is easily accomplished. 
Comment 51 danielmc 2001-12-14 04:38:52 PST
My understanding is that the user can still create the sentence themselves but
choose the variables from a drop down list rather than using %n values. 

This is somewhat akin to inserting field values in MS Word (Insert|Field...)

I think that this suggestion is a good one and potentially makes locaisation easier.
Comment 52 Alec Flett 2001-12-14 08:04:38 PST
mpt, there has been some agreement thus far that this is too complex a feature
to make the UI simple and easy to use... I think it is a waste of time and
screen real estate to have any complexity in this UI.
Comment 53 nhottanscp 2001-12-19 14:33:24 PST
Two proposals:
* Edit text fields (Comment #44)
* Drop down menu (Comment #48)

Or we could allow a localizer to provide localzied headers for reply and forward 
inline. Then UI would be just a checkmark (if that is checked then use the 
localzied headers and OS locale date format) and a static text for the 
explanation.
Comment 54 Erik Demaine 2002-01-01 22:25:54 PST
As a moderately advanced user, I would find helpful the ability to change the
reply line (AKA attribution), at least so that it can optionally include the
date.  I've been using Outlook XP for a while but am annoyed that it has no such
feature, so I switched to Mozilla (figuring if it's not there, I could add it).
 In Mozilla, I find hidden configuration items annoyingly tedious, and don't buy
the screen real estate argument (put it in another tab if necessary).  The
complexity of the interface is less of an issue for me, but it would seem that
it wouldn't hurt to spend some time and make it simpler to use.  Hope this
perspective helps.
Comment 55 nhottanscp 2002-01-17 21:59:52 PST
nsbeta1- per i18n triage
Comment 56 ji 2002-01-18 17:18:12 PST
Filed bug 120870 for a backend implementation that makes reply read the string
from .property file in case the user doesn't specify it in pref, so localization
engineers can have a choice to localize those strings in localized builds.
Comment 57 Aleksey Nogin 2002-04-13 13:24:38 PDT
And what about using different strings (in particular, in different languages)
in different situations - what selection strategies  would be reasonable to
support? Obviously, it makes sense to allow different strings for different
identities, but how about the following one:

- If I am responding to a message in charset=koi8 or with X-Accept-Language that
includes "ru", then use the Russian string.
- Otherwise, use the English one.

After all, Mozilla includes all those X-Accept-Language headers, we might as
well use them...
Comment 58 Matthew Paul Thomas 2002-04-17 19:00:33 PDT
> Can you explain how this UI handles word order differences among different
> languages in how the selected items are ordered?

Exactly the same as any alternative UI for it would. By editing the string. I 
completely fail to see how using %D instead of <Date> would be more acceptable 
for speakers of *any* language, unless that language happened to be xx-geek.

I also disagree that a 16-px-wide pulldown menu at the right of the text field 
is too high a price to pay for increased usability of the feature. I'm 
undecided on whether this should have a GUI, since allowing such customization 
tends to reduce the usability of Google Groups and other search tools over 
time; but if it's going to have a GUI, it might as well be a good one.
Comment 59 Nathaniel 2002-04-27 15:02:55 PDT
My 2 cents is that this shouldn't be exposed to users through the GUI. If an
advanced user wants a custom string, they can take the 15 minutes to edit a text
file. As it is, it looks like we're strapping space shuttle controls onto a
feature that is purely cosmetic.
Comment 60 Bart van Bragt 2002-09-10 05:23:16 PDT
Is nhotta still working on this? This bug has been silent for more than 4 months
now :\
Because I'm using Mozilla on several different computers and because I regularly
wipe my complete profile before an upgrade, I have to edit the
'mailnews.reply_header_type' pref quite often which is getting pretty annoying.

Main reason why I edit this pref is that the default doesn't include the date in
the header. Furthermore it would be extremely usefull if the header could be
altered to some kind of custom string, it would be nice if there could be a
(basic) userinterface for this.

BTW OS should be set to 'All'
Comment 61 nhottanscp 2002-09-10 10:05:28 PDT
>Is nhotta still working on this?
No, I do not plan to do this in near future.
Comment 62 M. Epstein 2002-09-28 10:28:15 PDT
I think it is really useful to have a date on original messages quoted in
replies; it's also pretty much a standard thing on mail clients. I understand
that it would be really nice to have a versatile UI that supports different word
orders and internationalization, but it seems it's going to take a while to get
an acceptable one of those. For the time being, wouldn't it be extremely
reasonable to show the date (perhaps localized in the most popular locale among
Mozilla users for the short term) as a default preference? Or at least a simple
UI feature for turning the date on and off? I think a lot of people will find
that to be a convenient interim measure until a "proper" UI that does everything
everyone wants can be designed and put into place. How about it?
Comment 63 Steve Wardell 2002-09-28 10:32:35 PDT
I'd like to second that idea in Comment 62 about adding a date. Personally, my
reason for support of this Bug is mainly so I can add the date such as:

"On Sept 27, 2002 at 11:30am, John Doe wrote:" (with or without the time,
whichever is more standard)

This change would lower the priority greater for me of a completely customizable
string.
Comment 64 Aleksey Nogin 2002-09-28 14:13:29 PDT
Re: comment #62, comment #63.

This bug is for pref *UI*. There is already a hidden pref that specifies whether
you want the date or not. If you want the date, just add

user_pref("mailnews.reply_header_type", 2);

to your prefs.js
Comment 65 Steve Wardell 2002-09-28 14:23:27 PDT
Then could we either:

1) make that preference be configurable in an interface (should be simple in
putting a checkbox somewhere)
2) Default that setting to be on

I think this would be a good interim step since sinces are moving slowly on the
full configurability UI.
Comment 66 nhottanscp 2002-09-30 14:33:07 PDT
>1) make that preference be configurable in an interface (should be simple in
>putting a checkbox somewhere)
I think that is a good idea. Please file a separate bug.

Comment 67 Steve Wardell 2002-09-30 17:57:05 PDT
Bug 171822 created to allow simple configuration of date in reply header.
Hopefully that will be a simple quick issue and this bug will not be as much of
an issue anymore for most people. 

Curiously, any reason this bug is not marked as an enhancement?
Comment 68 Manuel Silva 2003-05-07 20:07:19 PDT
I strongly agree with the possibility to "build" our own reply headers.

As I wrote at netscape.public.mozilla.mail-news and adding more stuff:
I think Mozilla development team should consider to add options to define
preface quoted message string... A field to write such thing like: "On %W
%d-%m-%Y %H:%i, %u (%e) wrote:"
where:
%w - day of the week (3 char long);
%W - day of the week (full-string);
%d - month day (without leading zero);
%D - month day (with leading zero);
%m - month number (without leading zero);
%M - month number (with leading zero);
%n - 3 chars. month;
%N - entire month-name;
%y - two digit year;
%Y - four digit year;
%h - hour (12 hour format - requiring %P);
%H - hour (24 hour format);
%i - minutes;
%s - seconds;
%G - local to GMT difference ("+01:00", for instance)
%P - AM/PM
%u - name of the original message sender;
%e - e-mail of the original message sender;
%S - Subject of the original message.

Arrays to:
%w, %W, %n and %N should be editable or according to a "locale" table.

It would be very useful and much more flexible than the existing way.

Building and interface as suggested on comment 48
(http://bugzilla.mozilla.org/show_bug.cgi?id=107884#c48) with possibility do set
date string format would be perfect.

By the way: does anyone knows how can I set my date format to this case
manually? My Mozilla formatted as mm/dd/yyyy hh:mm XX (where hh is a 12 hour
format and XX is AM or PM) and I wanted as dd-mm-yyyy HH:mm (where HH is a 24
hour format). How can I change it the way things are? (I'm using Mozilla 1.3
under RedHat Linux 8.0.)

Regards,

Manuel
Comment 69 Jason M. Abels 2003-06-17 11:41:03 PDT
*** Bug 78101 has been marked as a duplicate of this bug. ***
Comment 70 Charles Fenwick 2003-07-08 17:45:32 PDT
*** Bug 212092 has been marked as a duplicate of this bug. ***
Comment 71 Jean-Christophe Coynel 2003-10-23 07:26:35 PDT
About Manuel'S comments above, I believe some other fields should be added:
 - name and emails of the people who where CCed on this email
 - priority of the email
 - etc.

I am actually not sure if users need to be able to configure this down to that
level. The "forward" provides three different sets of headers (configured using
"mail.show_headers" = 1,2 or 3), which should satisfy most people. The confusing
part is that the "forward" and "reply" headers are different.

The "reply" part is done in nsMsgCompose.cpp, while the "forward" in
mimedrft.cpp, for what it is worth.

--JC
Comment 72 Alfonso Martinez 2003-12-05 09:55:25 PST
*** Bug 227575 has been marked as a duplicate of this bug. ***
Comment 73 Benedikt Kantus 2003-12-21 04:41:53 PST
*** Bug 229084 has been marked as a duplicate of this bug. ***
Comment 74 Hiro 2005-10-28 00:12:32 PDT
*** Bug 302142 has been marked as a duplicate of this bug. ***
Comment 75 Yusuf Pisan 2006-08-01 19:49:42 PDT
Supporting Manuel's comment. If this is an advanced preference, user should have full configuration options.

I want my reply header to say "Yusuf wrote on 1 Jan 2007: "

US versus UK locale is not sufficient since I correspond with both places, so would like to have the name of the month in the reply header.

Yusuf

(In reply to comment #68)
> I strongly agree with the possibility to "build" our own reply headers.
> 
> As I wrote at netscape.public.mozilla.mail-news and adding more stuff:
> I think Mozilla development team should consider to add options to define
> preface quoted message string... A field to write such thing like: "On %W
> %d-%m-%Y %H:%i, %u (%e) wrote:"
> where:
> %w - day of the week (3 char long);
> %W - day of the week (full-string);
> %d - month day (without leading zero);
Comment 76 Kosuke Kaizuka 2006-12-05 10:44:58 PST
Strongly supporting comment by Manuel and JC.
The difference between "reply" date header (denpending on OS format) and "forward" date header (rfc2822 format) confuses me.

(In reply to comment #68)
> I strongly agree with the possibility to "build" our own reply headers.
> 
> As I wrote at netscape.public.mozilla.mail-news and adding more stuff:
> I think Mozilla development team should consider to add options to define
> preface quoted message string... A field to write such thing like: "On %W
> %d-%m-%Y %H:%i, %u (%e) wrote:"
> where:
> %w - day of the week (3 char long);
> %W - day of the week (full-string);
> %d - month day (without leading zero);
> ...

(In reply to comment #71)
> I am actually not sure if users need to be able to configure this down to that
> level. The "forward" provides three different sets of headers (configured using
> "mail.show_headers" = 1,2 or 3), which should satisfy most people. The confusing
> part is that the "forward" and "reply" headers are different.
> 
> The "reply" part is done in nsMsgCompose.cpp, while the "forward" in
> mimedrft.cpp, for what it is worth.
Comment 77 Neil 2007-03-08 10:05:26 PST
I suggest the following:
Give an option for 1 ("Author"), 2 ("Author & Date"), 3 ("Outlook Style", the big block header), and 4 ("Custom").

On custom, prompt them for a string which would be held in mail.reply_header_custom, it would take arguments like strftime, but with the addition of a letter for From-Name and From-Email, and let them craft their own header.

Then put a checkbox for "Use same format for Forwarded emails."; if they uncheck it, they can do the same thing there.
Comment 78 HHahn 2007-07-02 00:29:51 PDT
I strongly agree with mr. Manuel Silva about the suggested possibility to build our own reply (and forward, and possibly redirect) headers.
Apart from details (like how many parameters should be made available), this is the only "correct" proposition for an international product like an e-mail client.

A strict difference should be made between (a) localizing the programme's user interface, and (b) the facilities offered to the user to write the document in the language he considers appropriate.

The user interface only addresses the user of the programme (in this case TB).
The message, however, may be written in a different language, for two reasons: (1) the user interface language may be different from the user's native language (e.g. if TB hasn't yet been localised for that language), and (2) the user may know several languages and be writing to a foreigner in a foreign language.

As for myself, my native language is Dutch, and I have a reasonably good command of English and an even better command of German. I am using the Dutch-localised version of Thunderbird, writing e-mails in all these three languages (and occasionally even in French).

It is obviously very impractical to have different menu options for reply headers in different languages. But is is also impractical to select a language version according to the OS locale (after all, I may be writing in another language than the OS locale language, which, in turn, may even be different from the e-mail client's UI language)!

When the user is given the possibility to write his own header strings, with only the parameters supplied by the programme, the entire "word order" discussion is obsolete. The basic problem in Thunderbird's implementation of mailnews.reply_header_etcetera is that portions of - necessarily language-dependent! - strings are supplied in fixed combination with the required parameters. This idea should, except for backwards compatiblity, be left.
Comment 79 HHahn 2007-07-02 00:35:39 PDT
Mr. Kosuke KAIZUKA said the difference between "reply" date header and
"forward" date header confuses him. I think the main difference should be the addtional text like "original message" (if replied to), or "forwarded messaged", or "redirected message".  This is only informative for the final receiver and IMHO does not need to affect the parameter format.
Comment 80 HHahn 2007-07-02 01:03:10 PDT
A small addition to my 2007-07-02 00:29:51 PDT comment (https://bugzilla.mozilla.org/show_bug.cgi?id=107884#c78):
In the second-last paragraph, I said that it is impractical to have different menu options for reply headers in different languages.
I forgot to mention the alternative, i.e. to use multi-language headers, like the one I use in my previous e-mail software (Courier):

  ----- Oorspr. bericht / Urspr. Bericht / Original message: -----

  Op 30-06-2007, om 22:41 uur, schreef John Doe (j.doe@somewhere.xy):
  Am 30-06-2007, um 22:41 Uhr, schrieb John Doe (j.doe@somewhere.xy):
  On 30-06-2007, at 22:41h, John Doe (j.doe@somewhere.xy) wrote:

This also illustrates how the word-order problem is solved.
Comment 81 Dan Kreene 2007-09-08 23:20:26 PDT
(In reply to comment #68)
> I strongly agree with the possibility to "build" our own reply headers.
> 


... and some room for "fortune cookie signature" style information ;)

To "randomly" choose a 

thus spake Bob
Bob rambled on and on
here's what Bob said


Comment 82 Maciej Jaros 2007-10-10 06:06:00 PDT
I've tried various %something thingies but most of them didn't work. TB crashed when I tried the custom header (4) and my last combo:
%Hour %Time %Date %hour %time %date %HOUR %TIME %DATE %a %A %b %B %c %d %H %I %j %m %M %p %S %U %w %W %x %X %y %Y %Z

Was anything said here implemented? I see that %i and %h gives some result (not sure what).
Comment 83 timeless 2007-10-11 14:05:02 PDT
egil@wp.pl: i'm confused, this bug isn't resolved, why would you expect anything suggested here to work?
Comment 84 Maciej Jaros 2007-10-15 10:56:09 PDT
(In reply to comment #83)
> egil@wp.pl: i'm confused, this bug isn't resolved, why would you expect
> anything suggested here to work?
> 

I just thought that some variables are available (as something seems to be) and the UI (or as I understand GUI) for this isn't ready yet. By the lack of answers I assume that nothing is ready yet.
Comment 85 HHahn 2007-10-16 04:27:23 PDT
I also heard that Mozilla is transferring (or plans to do so) Thunderbird to some other organisation because they have too much other work at hand.
If this is true, we may expect either a complete makeover or just a lack of interest in doing any more work on TB.
Comment 86 mika astel 2008-02-05 17:42:54 PST
I have also heard rumors like that.

http://www.hotelsincenter.com/
Comment 87 rsx11m 2008-04-25 12:07:57 PDT
Adjusting dependency after bug 258614 resolved as duplicate of bug 140377.
Comment 88 HHahn 2008-10-23 14:57:25 PDT
I don't see why this bug is a duplicate of bug 140377. The latter one seems to be only about e-mail addresses and/or names, whereas this current is about several other parameters (like date and time), and, above all, about using different message content languages, which may in turn even be different from the TB user interface language and/or the OS locale language! Please also see my comment no. 10 at bug 140377.
If you would like to see an example of a solution, just have a look at the Courier e-mail client (freely available from http://www.rosecitysoftware.com/Courier/).
Comment 89 rsx11m 2008-10-23 15:06:14 PDT
This is not a duplicate of bug 140377, but bug 258614 was, hence comment #87. Only the dependencies were changed here based on the bug 258614 resolution.
Comment 90 HHahn 2008-10-24 00:54:10 PDT
OK, thanks.
But I think you could better revert this bug to bug 450638, as that is a much "younger" entry and basically addresses the same problem.
Comment 91 rsx11m 2008-10-24 11:39:54 PDT
I'd think that bug 450638 has a different scope than this bug here, as it explicitly addresses the multi-lingual case of having correspondence in various languages, and thus to allow specifying alternate headings to reflect the language of the quote (possibly even with auto-detect). This could be accomplished with either the current reply-header prefs, just on a per-locale basis, or the templated strings suggested here. On the other hand, while the locale issue can be resolved with templated strings, there may be other use cases where you would like to build your own reply header independent of the language  question. Thus, these are two different things, both of them with their own relevance.

Also, I'm wondering if this bug here needs some retargeting. Per comment #61, the current assignee is no longer working on this bug, and the UI issue has
been spun-off to bug 171822 per comment #67. That bug has been won't-fixed recently, thus it appears that a UI is somewhat unlikely to happen.

The introduction of the template strings motivated in the discussion here is definitely desirable, with or without an elaborate user interface, and could be coordinated with a multi-locale approach suggested in bug 450638. Looking at
the original bug 70842 which introduced the current reply-header prefs, such a "free style" option was already envisioned by reserving the type-4 setting.
Comment 92 HHahn 2008-10-24 15:06:57 PDT
I agree that an elaborate user interface is not necessary for this functionality. Just an editing window (and a list of possible parameter stand-ins, like %a, %b, etc.) would do. More or less like the "QuickText" add-in (for editing standard signature texts etc.)

I am glad to see that rsx11m.pub@gmail.com call this feature "definitely desirable"...

One further aspect: automatic language detection does not seem very useful. The shorter the text, the less reliable such a detection is. If this automatich detection is included, it should also be possible to disable it.
Comment 93 HHahn 2008-10-24 15:09:21 PDT
Just one addition: The headers must also allow multi-line texts (e.g. if people want several different languages in the header, cf. comment #80 above
Comment 94 rsx11m 2008-10-24 19:23:13 PDT
The auto-detect idea came up in bug 450638 (you didn't vote for it yet, by the way) by tying the locale to the dictionary setting, for which such an RFE exist. As with every good feature, it should come with an "Off" switch, agreed.

The current header prefs allow line breaks already using the standard "\n" sequence, it's just not possible to enter it with the Config Editor. Such a capability should be retained for the templated version, which would also
make the OE-style heading (bug 218258) feasible.
Comment 95 HHahn 2008-10-25 02:26:42 PDT
This may not be the right place to ask this question, but you might be so kind as to answer it.
So far I did not find where and how to "vote" fot bugs. I presume this voting is used to determine the required priority or so. So it seems important. Bit the only voting thing I found, is the "My Votes" link, but that only seems to report votes, not allowing to cast them.
Comment 96 rsx11m 2008-10-25 06:18:19 PDT
Since the update of bugzilla, the votes can be found to the right of the "Importance" heading at the top left of the report. Click on "(vote)" next to "enhancement" and then check the respective (highlighted) box for the bug.
Comment 97 rsx11m 2008-11-15 11:05:07 PST
After consulting with Wayne on how to continue here, I'm going to make some changes as proposed in comment #91. This is no longer about UI design per se, and appears to be a not very useful main focus for this RFE after bug 171822 was won't-fixed. The discussion here goes more towards a back-end solution that would allow more flexible customization using template strings rather than a couple of fixed-order strings with fixed arguments (not excluding an additional UI option in the future). Such a more general solution would not only help with localization issues, but also provide the basis for a couple of related bugs asking for specific extensions to the reply headers.

 - Per discussion, I'm resetting the assignee to the default as nhottanscp
   does no longer seem to work on this;
 - changing the Subject line to reflect the current focus;
 - dependencies are upside-down then, a solution here would benefit some
   other bugs, thus blocking those.

This is of course open to further changes or discussion, in case I missed something or have overdone it.
Comment 98 Wayne Mery (:wsmwk, NI for questions) 2008-11-15 11:57:15 PST
I failed to mention that Bryan may have some ideas in this area.
Comment 99 Bryan Clark (DevTools PM) [@clarkbw] 2008-11-16 18:30:37 PST
I'd think the best way forward is to get the template system checked in such that different styles of header strings can be created.  Then create an extension (or two) that allow people manage edit those header strings.  The extensions make it easier to iterate over UI and allow people to try things out.  

In the end I think we'll want to stick with our mantra of simple defaults and powerful extensions.  Meaning an easy way ( drop down selection ) to choose a couple different common types of formatting will suite most users.  We can then offer ( inline to the selection ) extensions that help people get exactly what they want.  

If we can get some traction in bug 464621 I think our extension story will become much better.
Comment 100 HHahn 2008-11-17 01:35:23 PST
I am getting pretty confused with all those bug numbers, so if I am writing here at a wrong page please forgive me...

Somewhere I found an entry saying that editing header strings might be a "hidden pref". I agree that it will not be used frequently. Most people will edit their strings once and that's it.

However, don't forget that most people will do this at a time when they are still pretty new to Thunderbird. The biggest problem with hidden prefs is just knowing the name(s) of the pref(s) needed.

To wind up: If I am not mistaken, this very entry happens to be #100. Congratualtions! So when do we really get this feature...?
Comment 101 HHahn 2008-11-17 01:41:41 PST
Something went wrong in my previous entry (#100): while editing IU seem to have deleted one paragraph too many.

I was saying that most people only need this facility at an early stage uf their using TB. So the UI could be provided in an add-in, as long as the stings produced are stored independently of the add-in. This way, the UI add-in may be uninstalled later, thus reducing the time needed for TB to completely load.
Comment 102 rsx11m 2008-11-17 06:32:28 PST
(In reply to comment #100)
> However, don't forget that most people will do this at a time when they are
> still pretty new to Thunderbird. The biggest problem with hidden prefs is just
> knowing the name(s) of the pref(s) needed.

I would agree with that, which is also a problem I see with bug 448716 on reorganizing the preferences UI as a whole. There are many prefs that you
would only touch once and then forget about, but the urge to set them is sufficiently high to annoy the user if he or she can't find those anywhere.
So, the general question is where to set the threshold when a given pref "deserves" to be considered in the UI and when it can be safely "hidden" without causing too much trouble for users who can't find it.

For the case here, providing a couple of basic templates with a good default (currently switched to 2 for Thunderbird by bug 438375, to add another number) as suggested in comment #99, along with a basic UI to choose from those should be sufficient. I think though it wouldn't hurt but be beneficial to have a "custom" setting enabling a text field to freely enter the template (that's one UI item more, or could be hidden in an advanced modal dialog). Any more complex UI-guided specification of the template could go into an add-on. 

> To wind up: If I am not mistaken, this very entry happens to be #100.
> Congratualtions! So when do we really get this feature...?

First step would be the backend code, anybody here volunteering a patch? :-)
Comment 103 HHahn 2008-11-18 01:38:22 PST
A "workable" solution for many prefs might be manual page (e.g. a "help" page) with an alphabetic list of functionalities (in terms "understandable" by the end user), with the corresponding pref parameter name(s) and if necessary a short description or explanation. This would not even require a software change. The only "problem" would be that developers must not forget to update the list when software changes have been made.

Fot things like parameterised header strings, however, this solution would probably not suffice, as these strings require language-dependent versions.
Comment 104 Ilyse Kazar 2008-11-22 15:19:48 PST
should bug 290540 be added to the dep. tree?
Comment 105 rsx11m 2008-11-22 16:44:39 PST
Actually, no - that looks like a duplicate of bug 218926.
Thanks for pointing me to both bugs on the time zone.
Comment 106 Yann MERRIEN 2008-12-10 06:24:28 PST
I think the following add-on perfectly meets our needs: convenient UI to change the header, easy for beginers (standard headers) and possibility of string edit for advanced users.
https://nic-nac-project.org/~kaosmos/changequote-en.html
I think it should be included in the TB Preferences menu. (or at least in the https://addons.mozilla.org list)
Comment 107 Makoto Kato [:m_kato] 2008-12-12 19:42:34 PST
Created attachment 352821 [details] [diff] [review]
a patch
Comment 108 Makoto Kato [:m_kato] 2008-12-12 19:47:20 PST
This is my idea.  If you reply_type=4, use mailnews.reply_header_custom as reply header template.

ex)
user_pref("mailnews.reply_header_custom", "----- Original Message -----\nFrom: @F\nTo: @T\nDate: @D\n");
Comment 109 Onno Ekker [:nONoNonO UTC+1] 2008-12-12 22:56:44 PST
It is only in a commment, but there`s a tpyo in the patch:
// This handles custom reply heaser
s/heaser/header/
// This handles custom reply header
Comment 110 rsx11m 2008-12-14 08:22:15 PST
Good to see a patch posted for this! As a suggestion, a default could be defined with a definition in composeMsgs.properties, following comment #108

> mailnews.reply_header_custom=----- Original Message -----\nFrom: @F\nTo: @T\nDate: @D\n

for the localized headers, referred to in mailnews.js:

> pref("mailnews.reply_header_custom", "chrome://messenger/locale/messengercompose/composeMsgs.properties");

This would not just provide an example how to use a template but also immediately resolve bug 218258 in the process.
Comment 111 Makoto Kato [:m_kato] 2008-12-31 00:42:37 PST
Created attachment 354927 [details] [diff] [review]
patch v2

- Pref uses localized properties
- Fix typo comment
Comment 112 Axel Hecht [:Pike] 2008-12-31 06:42:43 PST
This should get a really thorough localization note. I read the comment in the code side, and can't really tell what string fragments are localizable and which aren't.
Comment 113 HHahn 2008-12-31 10:36:12 PST
I am afraid these last few comments are far beyond most of the users(!) who have submitted ideas for feature requests here...
Comment 114 Makoto Kato [:m_kato] 2009-01-06 01:45:06 PST
(In reply to comment #112)
> This should get a really thorough localization note. I read the comment in the
> code side, and can't really tell what string fragments are localizable and
> which aren't.

Axel, does it mean that new l10n string has to "LOCALIZATION NOTES" in comment of *.properties?
Comment 115 rsx11m 2009-01-15 06:00:03 PST
First of all, I like that patch, specifically the ability to have conditional strings as in "@!CCc: @C\n@!" to add a label only if, in this example, a "Cc:" header is actually present. This is also general enough to add further @-items proposed in the dependent bugs.

I'd agree with Axel that this needs some documentation though due to its complexity, as comments in the properties along with the localization note, or possibly better visible as comment in mailnews.js, stating the template syntax and meaning of the individual items.

Re comment #112, maybe some localization comment indicating the components to be translated by xxx or so would suffice? For example, "@!Cxxx: @C\n@!" to indicate the string that needs to be localized?
Comment 116 Maciej Jaros 2009-01-15 08:53:17 PST
(In reply to comment #115)
> First of all, I like that patch, specifically the ability to have conditional
> strings as in "@!CCc: @C\n@!" to add a label only if, in this example, a "Cc:"
> header is actually present. This is also general enough to add further @-items
> proposed in the dependent bugs.

Nice to see progress on this one, but that syntax is... well... horrible to understand and can be troublesome when new items (fields) will be added in the future. Let's say we want to add two letter codes - how could you tell if it's @C or @CC or even @CCc? And what about only-if in only-if?

I think this would be more readable: "@!{C}Cc: @C\n@{C}!". But what I would really prefer is something like: "@{@C ? 'Cc: @C\n'}". - which IMHO would be very natural for anyone that ever written something in C-like language. The proposed syntax could look something like:
@{@C ? '@C is not empty' : '@C is empty or not available'}
Comment 117 rsx11m 2009-01-15 11:37:30 PST
Well, if the choice is between "simple and doable for the next release" or
"nice but delays things", I'd tend to go with a more "simple" solution... :-)
Comment 118 HHahn 2009-01-16 01:14:04 PST
Conditions as in comment 115 are unneccessarily complicated. It is no probkem if a certain field in the header remains empty.

(Sigh) Discussions, discussions, discussions,...

The first message in this entire chain dates back from 31 October 2001, i.e. more than 7 (seven) years ago.

These discussions are for practical reasons written in English. But there plenty of people with a less good knowledge of English, or even none at all. That is one of the reasons localised versions of the software are supplied.
People DO NEED a solution as discussed here!

How long would it take to actually realise a simple solution? So when can we expect to find a useful and usable solution in Thunderbird?
Comment 119 rsx11m 2009-01-16 04:39:51 PST
(In reply to comment #118)
> Conditions as in comment 115 are unneccessarily complicated. It is no probkem
> if a certain field in the header remains empty.

Are you referring to my comment? Note that the patch presented here already *does* implement a mechanism for conditional strings, thus this should work right away as is up for review here. I agree that further complexity as suggested in comment #116 would be overdone. As a compromise, maybe replace the somewhat unintuitive '!' with brackets to make the conditions more clear, i.e., "@{Cxxx: @C\n@}", which should retain the current implementation.
Comment 120 HHahn 2009-01-16 12:37:26 PST
Re comment 119:

I tried to make clear that for a utility that is used only once in a while (at first configuration, and only occasionally after that), a pretty simple solution should be preferred. Just because it use used very infrequently, people have no opportunity to get used to the special syntax.

What I also was saying, is that this discussion is held in English, so readers may not be aware that the non-Anglosaxons among us are actually talking more or less "on behalf of" many others! So, as far as I am concerned, please stop discussing and try to have the requested functionality available soon. Why buy a sophisticated Mercedes when a simple Peugeot 107 would suffice?

On the other hand, I seem to have missed something. What add-in are you referring to that already had this?

Once again: I am not really waiting for conditionals or so, just for something like parameter stand-ins for a Quicktext-like plug-in.
Comment 121 rsx11m 2009-01-16 13:36:06 PST
HHahn, I'd like to get to a conclusion here as well and something that will be available with the next major releases of Thunderbird and SeaMonkey due in just a few months. Therefore, I agree that a simple working solution is desirable to finally get this done.

> What add-in are you referring to that already had this?

I was referring to Makoto Kato's patch, which is up for review by the module owners now to make a decision. This patch provides already the "conditional" options, it's just that the syntax is a bit tricky to understand. Therefore the comments on sufficiently documenting this in the code and/or making some minor adjustments to the syntax to make it more intuitive.

While I think that this likely goes into one more iteration for these changes, that patch "should be it" unless further issues are raised by the reviewers.
Comment 122 rsx11m 2009-01-18 15:30:32 PST
Makoto, looks like changing the "@!Cxxx: @C\n@!" to "@{Cxxx: @C\n@}" for emphasizing the boundaries of the conditions would involve only a few modifications in your current GetCustomReplyHeader() implementation:

> +      case '!':
> +        if (inCondition)
> +        {
> +          inCondition = PR_FALSE;
> +          if (canWrite)
> +            aReplyHeader.Append(header);
> +        }
> +        else
> +        {
> +          inCondition = PR_TRUE;

Changing to:

>>+      case '}':
> +        if (inCondition)
> +        {
> +          inCondition = PR_FALSE;
> +          if (canWrite)
> +            aReplyHeader.Append(header);
> +        }
>>+        header.SetLength(0);
>>+        break;
>>+      case '{':
> +        if (!inCondition)
> +        {
> +          inCondition = PR_TRUE;

Even if the brackets suggest that those can be nested, users would fairly quickly figure out that they can't, so that should be fine I think.

I've noticed that you already commented in detail on the @-modifies on top of that function, thus the only question would be if those should be repeated in mailnews.js to make them more visible for the user in the released versions.

And, I'm shutting up now - as said, this looks like a good solution...
Comment 123 Makoto Kato [:m_kato] 2009-02-01 19:29:47 PST
All, isn't there other objection?

If nothing, I will implement your suggestion.
Comment 124 HHahn 2009-02-02 00:23:14 PST
@Comment 123
No real objection. I only don't see what the "conditions" have to do with editable reply headers.
Comment 125 rsx11m 2009-02-02 06:16:54 PST
Their function is to avoid inclusion of text into the reply headers for information that does not exist (e.g., "Cc:"), so that's certainly useful.

As a reference, current Thunderbird 3.0b2 string freeze starts "slushy" 2/10, code freeze 2/12, thus would be good to have an updated patch for review.
Comment 126 Tom Pringle 2009-03-27 17:58:01 PDT
it seemed like all was left to do in early Feb was incorporate a slight
change and commit the code.  If that has not yet happened, (I conclude not
since I don't see this functionality in 3.0b2), is it still reasonable to think
this will happen in time for Thunderbird 3.0 release? if not then why not commit the existing patch.  It seems far better than nothing and, based on a quick read of this but history other related bugs, we've had nothing for quite some time.
Comment 127 rsx11m 2009-03-30 16:04:04 PDT
While the patch in attachment 354927 [details] [diff] [review] still seems to apply, it cannot
directly be used "as is" for the following reasons:

(1) Localization note (also mailnews.js?) needs to be added per comment #112;
(2) composeMsgs.properties is updated for mail/ only, not suite/ (breaks SM);
(3) optionally, change condition syntax per comment #122.

Nevertheless, this looks very feasible for inclusion into 3.0 and would either resolve or provide a template for several other bugs, thus nominating.
Comment 128 Dan Mosedale (:dmose) 2009-04-01 12:50:25 PDT
This doesn't block: if this were the last bug standing, we would indeed ship without it rather than further delaying getting the already-completed Tb3 work into the hands of users.

It feels like there are concerns around design complexity here, and the ideal next thing would be to hear from Makoto about his thoughts on this.  Makoto, do you still have the bandwidth to work on this patch/bug, or would it make more sense to look for another person to try and sort out the remaining issues?
Comment 129 Makoto Kato [:m_kato] 2009-04-01 18:12:49 PDT
I will make a patch this week, then send a review.
Comment 130 Magnus Melin 2009-04-02 07:16:24 PDT
(In reply to comment #128)
> It feels like there are concerns around design complexity here, 

I'd certainly second that. 
I'm not sure what use case it's *really* trying to solve? Sure, some people like to customize everything, but this seems a bit extreme.

This bug is long, but in the end, skimming through it very few people actually seem to request this kind of ability. A lot of comments are really about language selection / bugs in the existing prefs / not finding those prefs and/or not knowing how to use them. And the "outlook style" of reply headers - which is not this bug.
Comment 131 HHahn 2009-04-02 08:56:19 PDT
Mr. Magnus Melin, the whole point is that far too many people are not at all language-aware. They just don't care what language they write as long as it is more or less English ;-)
On the other hand, there is a vast number of people in the world that would prefer to write in other languages as well, depending on their addressees.

Of course they can write in the language of their choice (I am ignoring the aspects of different alphabets, which indeed make things more complicated.

The big problem with e-mail clients in this respect, however, is that there may be THREE languages involved, as I explained in my comment no. 78 above, and related comments.

The length of this comment list can also be seen as an indication for the actual need for the facilties discussed here. I agree, however, that in the course of time some vaguely related aspects have entered this topic, making it longer than necessary.

There will always be people who do not use each and every facility offered by a product. That does not matter, nor is it a reason for not offering those facilties, as other people may indeed use them.

The best way to "stop" this discussion is to start working on this problem and offering a real solution within a reasonable time. When good old Calypso/Courier was able to allow the user to edit his own header strings for Forward, Reply etc., so why isn't TB able to do so? The only(!) reason I switched away from Courier was its lack of Unicode and HTML support!
Comment 132 Dan Mosedale (:dmose) 2009-04-02 09:31:11 PDT
(In reply to comment #131)
> Mr. Magnus Melin, the whole point is that far too many people are not at all
> language-aware. They just don't care what language they write as long as it is
> more or less English ;-)
> On the other hand, there is a vast number of people in the world that would
> prefer to write in other languages as well, depending on their addressees.

While that is certainly the description of a problem, and addressing it is very worthwhile, it's extremely high-level and is the sort of thing that gets addressed by many bugs over time.  This bug is about a very tiny subset of that problem, and what Magnus is pointing out is that that subset doesn't seem to have a clear, specific use case that it's trying to address, which makes it very difficult to evaluate the design of the existing patch.

> The length of this comment list can also be seen as an indication for the
> actual need for the facilties discussed here. 

The length of this comment list would indicate that there is an actual need to address the high-level problem you described; it doesn't seem to indicate much about the specific solution proferred here.

> The best way to "stop" this discussion is to start working on this problem and
> offering a real solution within a reasonable time. When good old
> Calypso/Courier was able to allow the user to edit his own header strings for
> Forward, Reply etc., so why isn't TB able to do so? The only(!) reason I
> switched away from Courier was its lack of Unicode and HTML support!

Like most software projects, there is far more worthwhile work available to do than there are people with the expertise and time to do it. 

I think the thing that would be most helpful would be to hear more from Makato about what specific problems he is (and isn't!) trying to solve with his patch, as well as responses to some of the complexity questions posed by other folks here.
Comment 133 Magnus Melin 2009-04-02 12:51:02 PDT
(In reply to comment #131)
> Mr. Magnus Melin, the whole point is that far too many people are not at all
> language-aware. They just don't care what language they write as long as it is
> more or less English ;-)

I don't really see how this bug relates at all to languages (and afaikt, the patch doesn't really do much in that respect either).

If you have a use case for wanting to reorder the headers etc, please share it with the rest of us. I have no problem with an option to have the outlook style headers on reply, that's nice to have. I just questioned the need for the need for an option to do any more than that, at the cost of increased complexity.
Comment 134 rsx11m 2009-04-02 15:24:30 PDT
This bug has shifted its focus a couple of times, so let me try to review the history as I'd see it and where this is going. The main motivation initially
was that different languages may require a different order of the reply-header components. This is currently handled by a set of 5 (five!) preferences. An attempt to introduce a UI for those was made here, then moved into a different bug, thus leaving the issue of how to improve the reply header definition (I'm around comment #91 now when the bug was refocused respectively). See bug 485251 for a recent example on the effort to tweak the headers so that they work for a specific language, actually using a default-pref override in that case.

The idea of solving this with templates is as old as comment #21, without doubt introducing the greatest flexibility in defining the reply header. Additional bugs came up, asking for e-mail address (bug 140377) or time zone (bug 218926) to be added to the reply-header options (and yes, also fields to implement the dreaded OE-style headings). You could solve those by adding yet another bunch
of prefs, separately handling each case, or by generalizing the problem of both language-dependent word order and any future items that may be added to the reply headers. The OE-style headers as default came up in comment #108 to provide the user with a comprehensive example how the template pref is used
(and to conveniently catch bug 218258 in the process).

So, I'd say that the goal of this patch is to establish the framework for such an approach, both for localization and extension by further reply-header elements, and to have something useful ready in Thunderbird 3.0 already without entirely leaving the current system. On the long run, the template pref may
even replace the current set of prefs and should relate to locales as proposed in bug 450638. Thus, while this patch immediately would enable or simplify a limited number of use cases only, the bit more effort now should pay off when solving related issues in the future.
Comment 135 Karsten Düsterloh 2009-04-02 16:09:49 PDT
Hm, I remember talking about the basic issue a couple of times, but strangely enough not in this bug...

Basically, I think that the "solution" proposed here is making the existing nightmare even worse.

While it is indeed a relatively simple extension to the current way of doing custom mail introductions, it doesn't fix the actual stupidity of that system...

Let me quote from my 2007 summer of code project proposal:
> Currently, mail templates are too static, their interaction with
> mails you respond to etc. is almost zero (bug 21210, bug 107876 and
> others). It would be an enourmous progress if we could have variables
> like $$EMailAddress$$, $$QuotedBody$$, $$Date$$,
> $$CustomVariable(with Parameter)$$ in a [mail] template which get filled in
> when replying or composing.

If our mail templates would have this capability, we could get rid of these ugly bunch of prefs entirely and just ship some default mail templates...
Comment 136 Magnus Melin 2009-04-02 22:56:21 PDT
(In reply to comment #134)
>  See bug 485251
> for a recent example on the effort to tweak the headers so that they work for a
> specific language, actually using a default-pref override in that case.

That's about a bug/limitation in the current prefs. And it seems this bug wouldn't affect that...

> (and to conveniently catch bug 218258 in the process).

... at least not without breaking ^^^ for such locales.
Comment 137 HHahn 2009-04-03 01:27:48 PDT
Referring to mr. Karsten Düsterloh (#135):
"...just some default mail templates" would be OK if they are just examples and can be overridden bu user-defined templates. It is extremely impracticable - if possible at all -- to cover many languages in a few templates.

As I said earlier, just have a look at the current Quicktext add-on. This works fine. The only problem is that it completely lacks possibilities to use parameters like sender's name, date, etc. If this add-on could be extended with such a facility, and parallel with this TN would be modified to make these parameters available to plugins, the entire problem would be perfectly solved!

(As far as I am concerned, this Quicktext add-in might as well be included into TB)
Comment 138 rsx11m 2009-04-03 07:33:53 PDT
(In reply to comment #136)
> That's about a bug/limitation in the current prefs. And it seems this bug
> wouldn't affect that...

You are taking this out of context. Reason for citing bug 485251 was to show
an example how the current reply-header system is unsatisfactory despite its complexity, and what kind of tricks it takes to make it work. As I explained, the overall goal should be to start establishing a framework to get to a more generalized solution to the problem, and I'm happy to see that Karsten to this extent is on the same page here.

(In reply to comment #135)
> Hm, I remember talking about the basic issue a couple of times, but strangely
> enough not in this bug...

Yes, that was bug 171822 comment #25, dated 2005-09-10. ;-)

The idea of basing the entire reply off a template is certainly intriguing,
and would broaden the idea of generalization to the full message. It would
be a rather radical step though to throw away the entire current system of formatting the reply and replace it by a strict reply-with-template-only approach (which would also include quote positioning and some attribution in
the message body, if I understand you correctly). Note that this kind of full-message template could have its issues as well, e.g., "Dear $$author$$,"
may expand to "Dear xxx@yyy.zzz," if no real name is given, etc. In response
to comment #137, it is my understanding that the locale-specific default templates could be modified or used to derive custom templates, so this shouldn't be a restriction.

> While it is indeed a relatively simple extension to the current way of doing
> custom mail introductions, it doesn't fix the actual stupidity of that
> system...

I do not necessarily see a contradiction between introducing reply-header specific templates and the general message templates as long as one doesn't prevent the other from happening. The question is what can be realistically
done now for the upcoming releases while keeping a larger goal in mind.
Comment 139 R Benz 2009-04-03 16:47:07 PDT
(In reply to comment #106)
> I think the following add-on perfectly meets our needs: convenient UI to change
> the header, easy for beginers (standard headers) and possibility of string edit
> for advanced users.
> https://nic-nac-project.org/~kaosmos/changequote-en.html
> I think it should be included in the TB Preferences menu. (or at least in the
> https://addons.mozilla.org list)

Thunderbird Reset Quote Header Extension might also work for users if it supports Thunderbird 3:

* http://forum.addonsmirror.net/index.php?showtopic=1322
* Version 0.4.3 XPI: http://forum.addonsmirror.net/ext/extthunderbird/TB_Reset_Quote_Header_0.4.3.xpi
* Version 0.3.1 XPI: https://addons.mozilla.org/en-US/thunderbird/addon/760
* Author's Extensions: https://addons.mozilla.org/en-US/thunderbird/user/2058
* http://mac.softpedia.com/get/Internet-Utilities/ThunderBird-Reset-Quote-Header.shtml

Thunderbird Reset Quote Header Extension version 0.4.3 works great with Thunderbird 2 if you change the maxvers in the XPI.  Try updating the maxvers when testing with Thunderbird 3.
Comment 140 HHahn 2009-04-04 03:06:31 PDT
Referring to comment #139:
Good idea, however...

It take quite a bit of figuring and searching. E.g. the last link (...softpedia...) refers to a MacOS version. 
The reviews on e.g. the Mozilla site show that there are too many bugs, limitations etc. It is not made clear what the multi-language possibilities are.
Etc.
More relevant information would be needed, among which version information (and limitations), OS's for which it ia available, possibilities, etc.
Comment 141 Makoto Kato [:m_kato] 2009-04-04 08:00:46 PDT
Created attachment 371062 [details] [diff] [review]
patch v3

current test patch
Comment 142 rsx11m 2009-05-09 09:49:34 PDT
The v3 patch is a bit surprising, based on comment #128 I was expecting to see a reduction in code complexity, whereas the "@!CCc: @C\n@!" conditional case is now replaced with "@{@C ? Cc: @C\n@}" instead of "@{CCc: @C\n@}" as suggested. Also, I think the localization note would need more details, and SeaMonkey is still not included as your change affects MailNews Core.

This is somewhat stalling here - based on comment #133 and comment #135 some driver feedback would be good to see where this should realistically go, also in coordination with bug 450638 regarding multi-language options.
Comment 143 Ben Bucksch (:BenB) 2009-12-01 10:15:10 PST
See bug 13818. This looks like a dup of that.
Comment 144 rsx11m 2009-12-01 10:45:54 PST
You would usually dupe the bug without a patch to the bug which has a patch, but currently both bugs look rather abandoned (and bug 13818 seems at least to some extent to have asked for a line-by-line author reference in the quote).
Comment 145 rsx11m 2010-01-07 07:18:21 PST
While work here has obviously stalled, bug 218258 comment #60 points to an
add-on SmartTemplate which allows templated replies. This comes closest to Karsten's comment #135 for using full-message templates in replies. It is not
clear from the description whether or not conditional phrases are supported as proposed in the patches here, but it may help as a workaround for reply-header customization. Since templates are per account, to a certain extent the add-on
would also address localization (assuming different identities per locale).

https://addons.mozilla.org/thunderbird/addon/14662
Comment 146 Sirius 2010-02-19 22:44:10 PST
I suggest the reply header be generalised as the following 4 formats:
0: no reply header
1: compact - "On date, someone wrote:" 
2: full - "Date: %date \nFrom: %from \nTo: %to \nSubject: %subject \n"
3: custom - perhaps using str.find_and_replace() approach

These formats can be further customised to
1a: date first "On date, someone wrote:" 
1b: author first "someone wrote, on date:" 
1c: only author "someone wrote:" 
2a: include/exclude subject
2b: include/exclude CC
2c: include/exclude reply-to, importance, message-id...

I understand there is a near religious level debate on whether to use full header (2:) for reply.  Let's not go into that.  But as far as I am concerned, there are far more requests for full header(2:) than ability to customise compact header(1a: 1b: 1c:).  I think providing this option is the way forward.  We can leave this out of UI if it helps users to choose the best practise. 

I guess it shouldn't be too difficult to implement since the codes is already in mimedrft.cpp used by forward.  I do not understand why reply and forward use separate codes to handle their quoting and header in the first place.
Comment 147 HHahn 2010-02-20 07:55:31 PST
I'm afraid Sirius in comment 146 is wrong in his items 1a, 1b and possibly 1c. It is not a matter of just swapping the order of certain terms. Nor is it a "near-religous" debate. It is a matter of writing correct syntax in any language the writer happens to write in.

It seems to be typical Anglosaxon to not bother at all whether a text is syntactically correct and correctly spelled. Word order is strongly language-dependent. Also, there are (many!) cultures in the world where it is imply considered *impolite* to just jot down the words when and as the come up. There are languages where it is necessary to modify a grammatical ending of one or more words depending on whether it refers to a man or a woman, ot ro one or more people, etc. etc.

In the past years(!) quite a few people have tried to point this out in bug reports like this one. Several people, including Anglosaxons, are now convinved of this necessity. It is therefore unacceptable that someone now seems to try to reduce everything to simply swapping a word or two.
Comment 148 RDL 2010-02-21 09:03:45 PST
(In reply to comment #147)
> I'm afraid Sirius in comment 146 is wrong in his items 1a, 1b and possibly 1c.
> It is not a matter of just swapping the order of certain terms. Nor is it a
> "near-religous" debate. It is a matter of writing correct syntax in any
> language the writer happens to write in.
> 
> It seems to be typical Anglosaxon to not bother at all whether a text is
> syntactically correct and correctly spelled. Word order is strongly
> language-dependent. Also, there are (many!) cultures in the world where it is
> imply considered *impolite* to just jot down the words when and as the come up.
> There are languages where it is necessary to modify a grammatical ending of one
> or more words depending on whether it refers to a man or a woman, ot ro one or
> more people, etc. etc.
> 
> In the past years(!) quite a few people have tried to point this out in bug
> reports like this one. Several people, including Anglosaxons, are now convinved
> of this necessity. It is therefore unacceptable that someone now seems to try
> to reduce everything to simply swapping a word or two.
The entire relevant part of your post could have been conveyed without any references to "typical Anglosaxon" (typically Anglo-Saxon?) whatever that might mean. The points you make have very long been well understood by educated English people. As a fellow European you should know that. How speakers of the many other English language variants will react to your assertions I do not know but, because of the way it was phrased, I hope a moderator will remove your post.
Comment 149 HHahn 2010-02-22 03:48:50 PST
In reply to comment 148:
I agree that my first reference to "Anglosaxon" was rather unfriendly. I would apologise for that. The first sentence of the second paragraph ("It seems to be...correctly spelled") should indeed be removed.

I also agree that well-educated Anglosaxons are better informed. Actually, the sub-group I was referring to, is actually (part of) the software engineers. Generally, engineers are less "language-aware" than other people. (This is true in many language areas, not only English!)

What irritated me, was that someone (Sirius, in comment 146) tried to designate the long-running efforts to convince Thunderbird developers of the necessity for a more flexible language-dependency as a "near-religious debate".

On the other hand, I hope my grammatical errors (like "typical" instead of "typically", and undoubtedely several more errors) are understood as a signal that not everybody, though he or she may have a reesonable command of English, is not necessarily an Anglosaxon and may be writing Enlish as a foreign language.
Comment 150 Sirius 2010-02-24 07:01:35 PST
Re: comment 147, comment 149
The 'near religious debate' refers to whether to use compact(1:) or full(2:) style header in replies (as addressed in bug 218258).  It is not related language syntax at all.  My apology if I have not made this clear enough.  But please do not bring in unrelated topics into the discussion such as language and culture, as long as we are clear that there is a need to accomodate the differences of language syntax. 

The important point here is that the syntax of the compact style (1:) header should be flexible to accomodate different languages.  Some work has been done on this issue but perhaps not enough.  We need higher flexibility such as str.find_and_replace() style editable templates approach (title of this bug), instead of the existing append several variables in a pre-defined sequence approach. 

But in terms of usability, we should include a few default templates for most common styles in UI (eg. options > composition > reply and forward tab > dropdown list of 0: 1a: 1b: 1c: 2: 3:), while allowing customised template at about:config. 

(BTW, I'm from east asia)
Comment 151 HHahn 2010-02-24 07:55:30 PST
@Sirius, comment 150
Thanks for the clarification. However, be aware that there are several "confusing" aspects, especially for those (like me) who do not visit this discussion frequently. First of all, the topics ("bugs") are identified by numbers (like 107884). How can we quickly and easily see what each number exactly stands for? (The software of this site automatically changes the bug number into a link, so why doesn't it auromatically replace the number by the title (or add the title in parentheses, or so)? Btw., this is not to propose such a modification here; I am aware that should be done elsewhere. I am only illustrating that topics can just too easly be mixed up.)
Further, from the user's point of view (ergonomy!) there are quite a few of interrelations between translatability and selectable predefined texts. E.g., should all predefined texts be translatable? Sooner or later such discussions will arise.
Both translatability and predefined texts will require edits in the same part(s) of the software. So from the developers' point of view it seems much more convenient if these aspects are addresses in one action, as even a non-programming-experienced end user will understand (or at least presume).
As you see, my misunderstanding (which you just addressed) is not the only possible misunderstanding.
Comment 152 Raymond 2010-04-28 14:19:45 PDT
Would be very easy to have a simple option in such a way that the quote-header used when doing a "forward" will be applied with a "reply".
Comment 153 Raymond 2011-06-30 08:02:05 PDT
I just received a mail telling me that the status of this bug has been changed.
I see "ASSIGNED".
Would this mean that the patch will be a simple option to have for a reply the same header as with a forward ?
(related with https://bugzilla.mozilla.org/show_bug.cgi?id=595696 ?)
Comment 154 rsx11m 2011-06-30 08:06:56 PDT
It's still "assigned" since Makoto Kato took it on 2008-12-12, but nothing substantial changed after the last patch was posted. So this has stalled once again for the last two years and there doesn't seem to be any direction towards some solution that would be considered acceptable by the module owners (and given that there are different opinions among them if and what and how to change...).
Comment 155 Thomas D. (currently busy elsewhere; needinfo?me) 2011-09-10 23:38:12 PDT
Makoto Kato (assignee), are you still working on this bug?
Comment 156 Raymond 2011-10-14 15:26:22 PDT
A simple way of implementing could be that the reply header is the same as the forward header ...
Comment 157 rsx11m 2011-10-14 16:18:12 PDT
No, it is not. Please read the previous comments before adding a post. Thanks.
Comment 158 Thomas D. (currently busy elsewhere; needinfo?me) 2011-10-15 06:01:48 PDT
No reply from Makoto Kato (assignee) since he posted the last patch in comment 141 (more than 2 yrs ago on 2009-04-04).
Comment 159 Joe Smith 2011-10-16 04:09:53 PDT
(In reply to Raymond from comment #156)
> A simple way of implementing could be that the reply header is the same as
> the forward header ...

That would be all I need, too.
Comment 160 rsx11m 2011-10-16 15:45:15 PDT
That's bug 218258 though. The "Outlook-style" reply headers were only suggested as the default template here to (a) solve that bug in the process, and (b) to provide some reasonably complex example template that the user can start his or her own customizations from. Note that this bug here is not a replacement for the other reports, but may resolve some of them in the process if implemented as suggested.
Comment 161 Makoto Kato [:m_kato] 2011-10-16 18:18:38 PDT
I will handle this for Thunderbird 11.  (I have no resource until 10's timeframe)

(In reply to rsx11m from comment #160)
> That's bug 218258 though. The "Outlook-style" reply headers were only
> suggested as the default template here to (a) solve that bug in the process,
> and (b) to provide some reasonably complex example template that the user
> can start his or her own customizations from. Note that this bug here is not
> a replacement for the other reports, but may resolve some of them in the
> process if implemented as suggested.

My plan is that customized temple will become same Outlook style by this bug.  But users can customize it that they want.
Comment 162 Raymond 2011-10-17 16:03:07 PDT
(In reply to Makoto Kato from comment #161)
> I will handle this for Thunderbird 11.  (I have no resource until 10's
> timeframe)
> 
> My plan is that customized temple will become same Outlook style by this
> bug.  But users can customize it that they want.

PERFECT ... so we can use the template untouched ..and i hope that after implementing this in thunderbird 11 we will have it introduced in SeaMonkey ... Someone can tell us what will be the SeaMonkey version/release number ?
Comment 163 HHahn 2011-10-18 05:02:34 PDT
Well, does this really mean that this bug is now going to resolved soon? Just for sure, this bug was first filed on 31 October 2001, i.e. nearly TEN YEARS ago.

What can we learn from this as ro HOW to descibe future bugs in such a way that they do draw appropriate attention?
Comment 164 rsx11m 2011-10-18 06:44:15 PDT
So far it only means that Makoto has promised to post a revised patch (thanks!), which yet has to pass the reviews by a module owner or peer. Thus, even if a patch is posted, it doesn't necessarily imply that it will also be accepted.
Comment 165 Petr Vones 2012-06-06 02:04:34 PDT
Is there any progress on this ?

Meanwhile the SmartTemplate4 addon https://addons.mozilla.org/en-US/thunderbird/addon/smarttemplate4/ no longer works with Thunderbird 13.0.
Comment 166 Freddy 2012-06-21 14:43:58 PDT
Same question as Edmond, and a similar remark:

Until TB 12, I used successfully the very old addon 'TB Reset Quote Header' v.0.3.4. With TB 13, it's definitely broken. I had to revert to TB 12.
Comment 167 R Benz 2012-06-21 16:12:02 PDT
As a workaround, the extension "Change quote and reply format" version 0.7.4.2 still works with TB 13.0.1.  See http://nic-nac-project.de/~kaosmos/changequote-en.html, http://nic-nac-project.de/~kaosmos/changequote-0.7.4.2.xpi
Comment 168 Petr Vones 2012-06-24 11:56:59 PDT
There is fixed version of SmartTemplate4 which works with TB 13.x
Comment 169 Freddy 2012-06-24 16:33:50 PDT
Thank you for your advice. I tried now the kaosmos extension again, and it appears to work well now for html *and* textual replys. If not, I will try again Smarttemplate. 

But I prefer to have (please) an official flexible solution, including Outlook styled headers, and not to wait another 10 years (I was shocked to read this), and meanwhile use extensions that work more or less.

(I'm using TB at the office, because it's the suggested client of this university, unfortunately. And I see often reply headers like 'XY wrote at 23:59h'. No clue about who was included in a reply, and is therefore informed about a conversation)
Comment 170 Wayne Mery (:wsmwk, NI for questions) 2012-09-15 08:39:17 PDT
gentle ping to m_kato
Comment 171 Thomas D. (currently busy elsewhere; needinfo?me) 2012-09-15 10:30:40 PDT
*** Bug 787900 has been marked as a duplicate of this bug. ***
Comment 172 Raymond 2014-04-02 15:57:53 PDT
Were we informed when this bug will be corected and how to use the template ?
Comment 173 rsx11m 2014-05-13 18:18:33 PDT
Quick update here: Bug 995797 has simplified the multiple-preferences implementation to use one dedicated preference for each 1, 2, 3 type, defaulting to

  mailnews.reply_header_authorwrotesingle, "#1 wrote:"            (type 1)
  mailnews.reply_header_ondateauthorwrote, "On #2 #3, #1 wrote:"  (type 2)
  mailnews.reply_header_authorwroteondate, "#1 wrote on #2 #3:"   (type 3)

with #1 representing "From" and #2/#3 the day and time components of the "Date" header.

Note that this is still much less powerful than what was envisioned in the patches here, but certainly a step in the right direction.
Comment 174 Raymond 2014-05-17 13:32:45 PDT
Why not simply permit the reply header the same as the forward header ?
Comment 175 rsx11m 2014-05-17 16:53:48 PDT
I think we've been there...
Comment 176 Thomas D. (currently busy elsewhere; needinfo?me) 2014-05-18 01:44:35 PDT
(In reply to Raymond from comment #174)
> Why not simply permit the reply header the same as the forward header ?

Hi Raymond, yes, that's a reasonable request and you're not the only one. However, it's not "simply" as such because a lot of users will certainly prefer the current behaviour for their daily private correspondence. So we probably wouldn't want the "foward-inline-header-style" to be the default. Which means this involves offering alternative behaviours with good UX and without cluttering the UI. Which needs UI/UX decisions and a volunteer coder who's willed, skilled, and free to do this. More below...

(In reply to rsx11m from comment #175)
> I think we've been there...

Yes. We're actually pretty close in bug 67089 (6 duplicates, 18 votes at the time of this comment).
Comment 177 Raymond 2014-06-13 06:26:41 PDT
(In reply to Thomas D. from comment #176)


> ...we probably wouldn't want the "foward-inline-header-style" to be the default...

I agree, but it could be reasonable to have an option for using the same code as used by the "forward" action. If the product is well written ... it's then just to put one line of code like the following:
If inline-header-option is equal to 5 then call Forward-inline-header-style-function();
Comment 178 rsx11m 2014-06-13 06:46:09 PDT
Well, it's a different piece of code taking care of forwarding messages, so that wouldn't work as simply as you think. Having said that, everybody is welcome to post a patch, based on the current draft or come up with something new along the lines of the discussion (i.e., satisfying all use cases and not just the one you are personally interested in - which may be tricky given the fairly wide range of opinions voiced here).

I think it's safe to assume that Makato isn't working on this any more after 5 years of silence, thus resetting the assignee so that someone else can give it a fresh (or not so fresh) try.

Note You need to log in before you can comment on or make changes to this bug.