Open
Bug 13025
Opened 25 years ago
Updated 14 years ago
Use localized Re: for display only
Categories
(SeaMonkey :: MailNews: Message Display, enhancement, P3)
SeaMonkey
MailNews: Message Display
Tracking
(Not tracked)
NEW
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
Reporter | ||
Updated•25 years ago
|
Whiteboard: HELP WANTED
Comment 2•25 years ago
|
||
Just added myself to the Cc list
Updated•25 years ago
|
Assignee: nobody → putterman
Comment 3•25 years ago
|
||
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.
Comment 4•25 years ago
|
||
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.
Comment 5•25 years ago
|
||
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.
Comment 6•25 years ago
|
||
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.
Updated•25 years ago
|
Assignee: putterman → nobody
Comment 7•25 years ago
|
||
ok. This is a bit more complicated than I thought. Reassigning back to nobody@mozilla.org
Comment 8•25 years ago
|
||
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
Comment 9•25 years ago
|
||
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
Comment 10•25 years ago
|
||
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.
Comment 11•25 years ago
|
||
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 ?
Comment 12•25 years ago
|
||
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.
Comment 13•25 years ago
|
||
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:.
Comment 14•25 years ago
|
||
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
Updated•25 years ago
|
Keywords: helpwanted
Reporter | ||
Updated•25 years ago
|
Summary: [HELP WANTED] Use localized Re: for display only → Use localized Re: for display only
Whiteboard: HELP WANTED
Target Milestone: M20
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 15•15 years ago
|
||
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
Comment 16•15 years ago
|
||
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
Comment 17•15 years ago
|
||
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
Comment 18•15 years ago
|
||
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
Comment 19•15 years ago
|
||
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
Comment 20•15 years ago
|
||
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
Comment 21•15 years ago
|
||
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
Comment 22•14 years ago
|
||
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
Comment 23•14 years ago
|
||
This RFE is still valid...
Comment 24•14 years ago
|
||
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 → ---
Updated•14 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
You need to log in
before you can comment on or make changes to this bug.
Description
•