Open Bug 13025 Opened 25 years ago Updated 14 years ago

Use localized Re: for display only

Categories

(SeaMonkey :: MailNews: Message Display, enhancement, P3)

enhancement

Tracking

(Not tracked)

People

(Reporter: phil, Unassigned)

References

Details

(Keywords: helpwanted)

So the important thing about this is that we still have to send Re: and Fwd:
over the network, but we could localize the display.

    Subject: Localized Subject line ?
       Date: Thu, 02 Sep 1999 12:59:29 +0200
       From: Henrik Lynggaard <Lynggaard@netscape.net>
 Newsgroups: netscape.public.mozilla.mail-news

Hi

I don't know if this is implemented or going to be implented, but here
is the suggestion anyway:

Outlook has a feature where it uses localized versions of RE: in the
subject line, and many people in Denmark like this feature, however the
MS implementation is not very good, as it also transmits sv: over the
network and not re: as the standard tells it to.

My feature request: have mozilla change re: (and fwd:) into localized
versions when they are displayed on screen but keep their original
format when being sendt over the network

cheer from denmark
henrik
Whiteboard: HELP WANTED
*** Bug 13018 has been marked as a duplicate of this bug. ***
Just added myself to the Cc list
Assignee: nobody → putterman
actually, I'm just prepending the re: myself, so once I start using string
bundles, I can add to this to the property file and let everyone localize it as
they want.  Reassigning to me for that.  I'm not controlling the forward, maybe
David B can comment on that.
Now I read David B's comments about it being tricky to not send out that way.
Maybe I won't fix this then.  I'd have to talk to David B about that.
We need to carefully separate the "quoted" headers from the "UI" headers.
In 4.x, we translated UI headers like names of the input boxes for "To:",
"Subject:", etc. But we did not translate the headers which are directly
quoted from messages. These directly quoted headers are used in
quoting the original message entirely (inline forward, for example)
and in 4.x. We also showed the headers (partial or whole) we got from
the mail servers as they are (RFC822 headers) in the Message Viewing
window.

What IE5 does is simple use only the UI headers -- so they don't seem to
have our 4.x-type message viewing headers. However, it does quote the
original headers like we do when it reply/quote or forward. That is
at least what I observe in IE5-Japanese version. Henrik, please
take a look at the Danish version of OE 5 and see if you don't see the
original headers strings in reply/quote and forward.

In 5.0, we seem to be using a separate window for the header display.
If the headers there are simply UI headers, then that should be OK. (This
is much like IE5.) What we should not do is to mess with RFC 822 headers.
IE5-Japanese implementation does not translate "re:" or "fwd:" --
the Danish version probably over-translated these.

If you really wanted to see this kind of this display, one idea
would be to reflect the presence of "re:" and "fwd:" in the RFC 822
headers in the UI headers like this:

"Subject (Re:"): Re: Some issues

where the UI header part in double quotes will be translatable
but we keep the original headers as they are.
Assignee: putterman → nobody
ok.  This is a bit more complicated than I thought.  Reassigning back to
nobody@mozilla.org
Sorry, I misplaced the closing double-quote. It should look like:

"Subject (Re:)": Re: Some issues

For English, this might be translatable as:

"Subject (Reply)": Re: Some issues
shouldn't Mozilla snap the additonal RE: so that there always is only one Re: ??

that's namely one of the big problem of MS's way, other news readers dont
recognize the sv: and worst case scenario is something like re: sv: re: the real
subject.

So I'm guessing that once the code for having only one Re: is in, it should be
fairly easy to do something like
Subject_on_screeen = localized_re + subject - 3 first characters

and when sending simply send RE: + (subject_from_screen - localized_re)

doesn't sound that hard, but I'm no C++ guru
None of this is hard conceptually. The hard part is to make absolutely sure the
sv: doesn't accidentally leak out...if we stick it in the rdf node, we run the
risk of someone querying for the subject property and letting it out into the
real world.
Well, As I see it the rdf node should do something like this:

subject = The Real subject
isReply = true

and the user should see:

reply_prefix + subject = SV: the real subject

and the network do:

if (isReply)
{
  transmit ("RE: "+ subject)
}
else
{
  transmit (subject)
}

What I mean is that we define the subject to be the REAL subject that is without
prefixes. same goes with FWD: / VS:

or am I completely off ?
that's what the database does already. The message rdf node gives the string to
the tree control to display, so it has to do the transformation. The tree
control has no mail/news semantics.
Right now I'm using RDF for display purposes in which case the subject is going
to return the Re: added on.  If you are using js you could get the nsIMessage,
get the subject and then do whatever you like regarding re:.
Couldn't a extra tag/information be made in the RDF messagenode like this

String Real_subject
String display_subject
boolean isReply
boolean isForward
.. other stuff

then puttermans displaycode queries display_subject instead of real_subject

I guess the rdf node is created by some network code that reads the message from
the network code, so it knows the mail/news semantic and can set both strings.

The problem is then on the way back if the user has changed the subject
line,when the network code needs to remove the sv: part of the display and
replace it with a re:

perhaps this could be solved in the ui by making the editable subject (in the
message compose use the real_subject and not the display subject.

this way however the user cannot manipulate Sv: or re:, but that I think is not
a great loss
Keywords: helpwanted
Summary: [HELP WANTED] Use localized Re: for display only → Use localized Re: for display only
Whiteboard: HELP WANTED
Target Milestone: M20
QA Contact: lchiang → nobody
Product: Browser → Seamonkey
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
This RFE is still valid...
We do already have the pref mailnews.localizedRe which allows for user-defined replacement of such localized stuff. It's only used when building the msf data, but replies use that to build the outgoing representation...
Status: RESOLVED → UNCONFIRMED
Resolution: EXPIRED → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.