Open Bug 107884 Opened 23 years ago Updated 2 years ago

Introduce editable templates for reply header strings

Categories

(MailNews Core :: Localization, enhancement)

enhancement

Tracking

(Not tracked)

People

(Reporter: nhottanscp, Unassigned)

References

(Blocks 8 open bugs)

Details

(Whiteboard: [patchlove][has draft patch])

Attachments

(1 file, 5 obsolete files)

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.
Reassign to nhotta, cc to ducarroz, jglick, momoi, putterman.
Assignee: rchen → nhotta
Target Milestone: --- → mozilla0.9.7
Status: NEW → ASSIGNED
Keywords: l12y
My personal opinion is that I would keep this as a hidden pref.
Agree. Not sure I see the need for a visible pref.
putterman, glick,
Do you think the user usually not want to edit those strings?
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?
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.
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.
removing l12y
Keywords: l12y
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.
Where would this ui go? Global Mail prefs? Per Account settings? (global 
probably the best option)
I agree, I don't think we need per account settings for the strings.
Attachment #57973 - Attachment is obsolete: true
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.
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
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?
> 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.
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!)
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.
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"?


Target Milestone: mozilla0.9.7 → mozilla0.9.9
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. 
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?
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?
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.
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?
Each successive attachment makes me want to hide this pref even more!
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...
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?
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.
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. 
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!)
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. 
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?
> * 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:

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.
Nominating.
Keywords: nsbeta1
> 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. 

I misunderstood the comment #35. But how the user can know the usage of %Date?
> 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).

I prefer ASCII date to be a default, because locale date may not be readable if
the recipient does not have the same locale.
> 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.

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
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?

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.
How about %D for ASCII date %d for OS locale date?
What case is %R or %N used?
> 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:

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.
> 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?

> 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. 
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.
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.
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.
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.
nsbeta1- per i18n triage
Keywords: nsbeta1nsbeta1-
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.
Target Milestone: mozilla0.9.9 → mozilla1.2
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...
> 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.
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.
Target Milestone: mozilla1.2alpha → Future
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'
OS: Windows 2000 → All
Hardware: PC → All
>Is nhotta still working on this?
No, I do not plan to do this in near future.
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?
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.
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
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.
>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.

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?
Depends on: 171822
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
*** Bug 78101 has been marked as a duplicate of this bug. ***
Blocks: 171047
*** Bug 212092 has been marked as a duplicate of this bug. ***
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
*** Bug 227575 has been marked as a duplicate of this bug. ***
*** Bug 229084 has been marked as a duplicate of this bug. ***
Depends on: 258614
Product: MailNews → Core
*** Bug 302142 has been marked as a duplicate of this bug. ***
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);
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.
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.
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.
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.
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.
(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


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).
egil@wp.pl: i'm confused, this bug isn't resolved, why would you expect anything suggested here to work?
(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.
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.
I have also heard rumors like that.

http://www.hotelsincenter.com/
Adjusting dependency after bug 258614 resolved as duplicate of bug 140377.
Depends on: 140377
No longer depends on: 258614
QA Contact: ji → localization
Product: Core → MailNews Core
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/).
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.
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.
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.
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.
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
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.
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.
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.
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.
Assignee: nhottanscp → nobody
Status: ASSIGNED → NEW
No longer depends on: 140377
Summary: Pref UI for editable reply header strings → Introduce editable templates for reply header strings
Attachment #60663 - Attachment is obsolete: true
I failed to mention that Bryan may have some ideas in this area.
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.
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...?
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.
Depends on: 464621
(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? :-)
No longer depends on: 464621
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.
Blocks: 218926
should bug 290540 be added to the dep. tree?
Actually, no - that looks like a duplicate of bug 218926.
Thanks for pointing me to both bugs on the time zone.
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)
Attached patch a patch (obsolete) — — Splinter Review
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");
Assignee: nobody → m_kato
Status: NEW → ASSIGNED
Attachment #352821 - Flags: superreview?(bienvenu)
Attachment #352821 - Flags: review?(bienvenu)
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
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.
Attached patch patch v2 (obsolete) — — Splinter Review
- Pref uses localized properties
- Fix typo comment
Attachment #352821 - Attachment is obsolete: true
Attachment #352821 - Flags: superreview?(bienvenu)
Attachment #352821 - Flags: review?(bienvenu)
Attachment #354927 - Flags: superreview?(bienvenu)
Attachment #354927 - Flags: review?(bienvenu)
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.
I am afraid these last few comments are far beyond most of the users(!) who have submitted ideas for feature requests here...
(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?
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?
(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'}
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... :-)
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?
(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.
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.
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.
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...
All, isn't there other objection?

If nothing, I will implement your suggestion.
Attachment #354927 - Flags: superreview?(bienvenu)
Attachment #354927 - Flags: review?(bienvenu)
@Comment 123
No real objection. I only don't see what the "conditions" have to do with editable reply headers.
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.
Blocks: 479626
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.
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.
Flags: blocking-thunderbird3?
Whiteboard: [needs new patch]
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?
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-
I will make a patch this week, then send a review.
(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.
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!
(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.
(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.
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.
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...
(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.
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)
(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.
(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.
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.
Attached patch patch v3 — — Splinter Review
current test patch
Attachment #354927 - Attachment is obsolete: true
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.
See bug 13818. This looks like a dup of that.
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).
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
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.
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.
(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.
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.
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)
@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.
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".
Blocks: 666923
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 ?)
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...).
Makoto Kato (assignee), are you still working on this bug?
Depends on: 694514
A simple way of implementing could be that the reply header is the same as the forward header ...
No, it is not. Please read the previous comments before adding a post. Thanks.
No reply from Makoto Kato (assignee) since he posted the last patch in comment 141 (more than 2 yrs ago on 2009-04-04).
Assignee: m_kato → nobody
Status: ASSIGNED → NEW
(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.
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.
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.
Status: NEW → ASSIGNED
(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 ?
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?
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.
Depends on: 733258
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.
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.
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
There is fixed version of SmartTemplate4 which works with TB 13.x
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)
gentle ping to m_kato
Assignee: nobody → m_kato
Target Milestone: Future → ---
Were we informed when this bug will be corected and how to use the template ?
Blocks: 13818
See Also: → 243001
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.
Why not simply permit the reply header the same as the forward header ?
I think we've been there...
(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).
See Also: → 67089
(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();
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.
Assignee: m_kato → nobody
Status: ASSIGNED → NEW
Whiteboard: [needs new patch] → [patchlove][has draft patch]
Type: defect → enhancement
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.