Open Bug 471487 Opened 16 years ago Updated 2 years ago

Try to straighten out situation with mimeheader.properties and mime.properties

Categories

(MailNews Core :: MIME, defect)

Product:
MailNews Core
Component:
MIME
Type:
defect

Tracking

(Not tracked)

People

(Reporter: philor, Unassigned)

References

Details

(Whiteboard: [needs a plan]) 

mimeheader.properties is a localized list of header names, with no localization notes other than instructions to not localize the "CC" and "BCC" and "FCC" parts of strings where those occur.

mime.properties is (among other things) a localized list of header names, with no localization notes (for those strings) other than instructions to not localize the "CC' and "BCC" and "FCC" parts of strings where those occur.

That would just be the usual way we are, duplicating stuff without realizing it, except that both of those sets of header translations are accessed from a single spot, in nsMimeBaseEmitter::LocalizeHeaderName, which is both a liar and confused about what it is doing.

Bug 157979 intended that what would happen is when LocalizeHeaderName(OrDont) is called, if mFormat is neither nsMimeMessageQuoting nor nsMimeMessageBodyQuoting, then it would localize the header name, by getting the id number from a map, then calling MimeGetStringByID to get a localized name from mime.properties. If, however, mFormat was a quote, or if MimeGetStringByID fails, it would use the name to look up a string in mimeheader.properties, "the other bundle (usually not translated)" and if that also failed, would return the default name that the caller passsed it.

That was supposed to allow the Japanese localization to use Japanese names for headers while printing, without using them and confusing (or breaking? the bug is unclear about why the strings in forwards must not be localized) people when a Japanese user forwarded a message. It might have actually worked, at some point, but because that bug did absolutely nothing to ensure that the headers in mime.properties were not localized, but that the ones in mimeheader.properties were, we now have the situation where we have the same strings it two different files, in most cases localized in both, but for some unfathomable reason, maybe collective memory of the time before that bug landed, not translated in either file in either Japanese locale for either mail product.

The solutions are all pretty straightforward:

* If header names in forwards must really never be localized, move the file where we get them out of the locales, into mailnews content. (CVS actually still has unjarred unlocalized unused copies of both in mailnews/mime/resources/).

* If header names in forwards really should always be localized, remove one of the two copies.

* If header names in forwards should actually be localized in some cases, for some locales, and should not be localized in other cases, for other locales, then the two copies should have localization notes explaining which is which, why there are two, and how to decide what to do with each.

Deciding which is the correct solution, though, isn't so straightforward.

Do native Japanese (or Chinese, or Korean, or Farsi, or Hebrew, or Cyrillic) email programs translate header names in forwarded messages? Do other localized CJK or non-Latin email programs translate them? Do English-speaking recipients of such forwards say "omg, you broke my mail!"? Do native or localized non-CJK email programs in more-Latin languages translate header names in forwards?
Ad 1, the ID crap in mailnews should die wherever we can kill it.

It'd be nice to get a bit of testing for the following scenarios:

Forwarding mails inline. Can we localize the headers in a inline-forwarded mail for display? If so, we shouldn't translate the headers. If not, one can still argue on which is more user friendly, translating or not. I'm slightly leaning towards translating, putting more weight on the scenario where Japanese folks forward mails to Japanese folks than to me.

Forwarding mails as attachment. Same questions as above, but I assume that we can display localized header fields on reading a forwarded mail as an attachment. I'd be on the side of keeping the received mail intact as much as possible here. If we can't display the headers in the readers language, I'd consider that a bug.

Printing mails. This is a slightly different scenario, IMHO, as printing a mail is most likely for one's own use, thus I'd recommend to print them as displayed, with localized header keys.

Did I miss a scenario?

CCing Bryan for some UE guidance.
(In reply to comment #0)
> Do native Japanese (or Chinese, or Korean, or Farsi, or Hebrew, or Cyrillic)
> email programs translate header names in forwarded messages? Do other localized
> CJK or non-Latin email programs translate them? Do English-speaking recipients
> of such forwards say "omg, you broke my mail!"? Do native or localized non-CJK
> email programs in more-Latin languages translate header names in forwards?
I've tested few e-mail programs with Russian interface. MS Outlook 2003/2007, Outlook Express and GMail don't localize header names in forwarded messages, Opera Mail and Evolution localize header names in forwarded messages. I haven't received complaints from English-speaking recipients.
(In reply to comment #2)
> Opera Mail and Evolution localize header names in forwarded messages. I haven't
> received complaints from English-speaking recipients.

That's not really an argument pro/contra anything. Most people are email-illiterate anyways. :-P

Strangely enough ;-), I'd agree with Axel's comment #1:
- get rid of numeric ids
- translate when printing or forwarding inline
- do not translate when forwarding as attachment (or saving as .eml, 
  which is basically the same case)
(In reply to comment #3)
> (In reply to comment #2)
> > Opera Mail and Evolution localize header names in forwarded messages. I haven't
> > received complaints from English-speaking recipients.
> 
> That's not really an argument pro/contra anything. Most people are
> email-illiterate anyways. :-P
I haven't said that it was argument pro/contra, I just has answered Phil's question.
 
> 
> Strangely enough ;-), I'd agree with Axel's comment #1:
> - translate when printing or forwarding inline
I agree that headers should be printed as translated, but I'm not sure that it's good idea to translate them in messages forwarded inline.
I think as a general guide we should be using the users preferred language with our translations whenever we control the display.  To me forwarded headers fall into this category of user content.  

I (as an english speaker) wouldn't expect to see headers in a forwarded mail in some other language so that makes me believe the same is true for non-english speakers. (in print or mail)
(In reply to comment #5)
> I think as a general guide we should be using the users preferred language
> with our translations whenever we control the display.  To me forwarded
> headers fall into this category of user content.  

Just "forwarded" doesn't suffice as a distinction. In fact, we should even be more precise and (for forwarding) look at:
- inline vs. attachment
- all headers vs. some headers

> I (as an english speaker) wouldn't expect to see headers in a forwarded mail
> in some other language so that makes me believe the same is true for 
> non-english speakers. (in print or mail)

I, as non-English speaker, wouldn't expect an attached(!) mail be altered in any way, thus expecting "raw" English headers in the attachment. If I then display this message not as mere text but as an _email_, I'd expect the headers names to be translated.
Inline forwarding, otoh, is more a special kind of quote, so the expectation of no changes isn't that high.
for the IDs I think you're refering to reference headers, they have been removed, see bug 464782

(In reply to comment #6)
> Just "forwarded" doesn't suffice as a distinction. In fact, we should even be
> more precise and (for forwarding) look at:
> - inline vs. attachment
> - all headers vs. some headers

For inline forwards (reminder that this is the default now) I think it's fairly clear that we want to translate the headers included in the forward.

For attached forwards I think you're right that many people wouldn't expect those to be altered or translated so we should leave them unchanged.  I'm a bit unclear to which point this would actually be done.  In the display of an attached message it would be possible to translate the headers properly, however we couldn't do that to a message we were sending as there is no inline content like there is with an inline forward.  Unless I'm missing something.

I'm a bit unsure how we distinguish all headers vs. some headers.  I've been working off the assumption that "headers displayed" in an inline forward would be translated.  These headers aren't actual message headers as much as they are derived or created from the message and inserted into the forwarding content.  

We can't translate actual message headers because a person would no longer be able to parse and view the message; I'm not sure what the purpose would be unless we are hoping people are viewing the message source.
(In reply to comment #7)
> For inline forwards (reminder that this is the default now) I think it's fairly
> clear that we want to translate the headers included in the forward.
Can you please explain why you think that translating the headers included in the forward is good idea? Headers in forwarded messages are information intended for recipient of message and we have no idea if recipient can understand language of localized headers.
As for example, if user of Chinese Thunderbird would forward me letter, I'd got it with headers localized in Chinese (which I don't speak). I can only make guess that it's probably headers.
Idea of localized headers works good only in case if both sender and recipient speaks same language.
When forwarding a mail inline, you can actually edit the mail contents in TB. Thus, when reading a inline-forwarded mail, the user agent can't really translate the headers on the fly. When forwarding as attachment, the reader can surely do that, as the attachment conforms with the RFC (or at least should).

So, in the case of a forward as attachment, we can rely on the UA rendering the forwarded mail optimally for the language settings of the recipient, which we can't do for forwards inline.

At least that's my assumption, and reading this bug, is a general assumption.

I wonder if that assumption really strongly holds.

Anyway, if we cannot have the UA of the recipient render the headers in the preferred language of the recipient, then we have to make an educated guess, and IMHO, assuming that the sender and the recipient speak the same preferred language sounds more valid than the assumption that the recipient speaks English. But that is really a compromise, which is why I CCed Bryan in the first place.

The global UE of forwarding inline makes me wonder if that's really a good default internationally. Bryan, is there a bug with a rationale for doing that?
If you forward a message inline, it's actually "just" a mail. I don't know of *any* UA who tries to distinguish between "normal" mail content and inline-forwarded mail content. 

(In reply to comment #9)
> Anyway, if we cannot have the UA of the recipient render the headers in the
> preferred language of the recipient, then we have to make an educated guess,
> and IMHO, assuming that the sender and the recipient speak the same preferred
> language sounds more valid than the assumption that the recipient speaks
> English.

The assumption is not "recipient speaks English", but "recipient knows the technical header names" (which, by mere coincidence, happen to be plain English words)...
FWIW, there is some discussion on localization of headers in reply/forward mails in Bug 107884
> The global UE of forwarding inline makes me wonder if that's really a good
> default internationally.

I highly doubt anyone is very confused by this, especially if it's english. (People are so used to it.) The rationale for forward inline was that everybody else does it - and "as attachment" *is* confusing to a lot of people, because the usage is small.
Sorry, I should have known better than to ask so vaguely. There are five different cases, only one of which I meant.

When we send a forward as attachment, as people have noted, we send the complete original email, which is the right thing to do.

When we receive a forward inline, we display whatever it was that we got, which is the right thing to do.

When we receive a forward as attachment, and you're viewing attachments inline, we create a header block displayed inline, with the Subject/From/Date/To headers from the original email translated, which is probably the right thing to do, but could be impacted by this bug (if, say for exaggeration, we decided to remove every trace of localized strings).

When we send an inline forward while you are in View - Headers - All mode, we include all the headers inline, untranslated, which is almost certainly the right thing to do (you generally only forward all headers when you're doing it for forensic purposes, in which case the recipient wants the actual header names, not a translation), and although that's not great UI, that not-greatness is not this bug.

When we send an inline forward while you are in View - Headers - Normal mode, which is the one thing I wanted to ask about, we include just the Subject/Date/From/To headers (go us, a different order than the received attachment, and both are different than Thunderbird's current envelope order), and whether or not those are translated depends on the decision that the localizers have made about a bunch of strings in mime.properties, strings which do not have any localization notes, but which Netscape's i18n engineers thought (with no apparent reason for thinking so) would not be translated, because as Frank Tang said at the time, "For forward inline, if we translate it, we will have problem."

Of course, nobody ever bothered to say *what* that problem would be, whether it was the fear that English-speaking correspondents of Japanese speakers would have a client incapable of rendering Japanese, or incapable of handling the charset we would send, or we would have problems shifting an ISO-8859-15 email into something that we could manage to include the Japanese header names in, or perhaps it was just the social problem that a ne-NP speaker forwarding an email to an English speaker doesn't want to baffle him with a header block saying

विषय: [Bug 471487] Try to straighten out situation with
मिति: Tue, 30 Dec 2008 11:25:26 -0800
बाट: bugzilla-daemon@mozilla.org
लाई: philringnalda@gmail.com 

(Which I would probably find normal if I spoke Nepali, pretty cool if I had a Nepali-speaking friend who was forwarding something in English to me, and a problem that needed to be fixed if I had a Nepali-speaking employee forwarding me English email about our business-conducted-in-English with Nepali header labels.)

But as you can see from <http://mxr.mozilla.org/l10n-central/search?string=1000.*%3D&regexp=on&find=%2Fmime.properties> in pretty much every case (for finished locales) *except* Japanese, we are already using translated header names for forwarding inline, as far as I know without reported problems. The Japanese case is odd since despite that being the language for which we switched to getting headers from different files for printing and forwarding inline so they could be localized for printing, right now none of ja, ja-JP-mac or ja/suite/ have either set localized.

I guess the most reasonable conclusion from that is that we should have a single set of header name strings, used for sending forwards inline, printing, and receiving forwards as attachments, without localization notes so it's entirely left up to the localizers to decide, and either file a bug on ja to say it's okay to translate them, or leave them alone to make their own decision.

Two alternate conclusions are that we should have two sets even if only one language chooses to have them different, and should file a bug on ja to say which one it's okay to translate and should have l10n notes explaining which is which, or, that we should have two sets even if every current locale chooses to have them the same in both cases, though I don't much like the premature unoptimization of the latter.

(And yeah, I *know* the numeric keys are evil, I *know*. I have two separate patches removing something like 16 of them that are unused, and I can't be changing keys until I get rid of those.)
(In reply to comment #13)
> But as you can see from
> <http://mxr.mozilla.org/l10n-central/search?string=1000.*%3D&regexp=on&find=%2Fmime.properties>
> in pretty much every case (for finished locales) *except* Japanese, we are
> already using translated header names for forwarding inline, as far as I know
> without reported problems. The Japanese case is odd since despite that being
> the language for which we switched to getting headers from different files for
> printing and forwarding inline so they could be localized for printing, right
> now none of ja, ja-JP-mac or ja/suite/ have either set localized.
There is comment from Japanese localizers in Bug 70842 comment #8 regarding non-localization for some of these strings.

> it's
> entirely left up to the localizers to decide, and either file a bug on ja to
> say it's okay to translate them, or leave them alone to make their own
> decision.
Should we also take in account "other mail clients behavior" factor?
Whiteboard: [needs a plan]
Realistically, having this unassigned would be more accurate, just in case someone with a miraculously workable plan comes along.
Assignee: philringnalda → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.