Open Bug 1201836 Opened 6 years ago Updated 5 years ago

Reply to e-mail with the correct dictionary set (based on Content-Language header)


(MailNews Core :: Composition, enhancement)

Not set


(firefox43 affected)

Tracking Status
firefox43 --- affected


(Reporter: jorgk-bmo, Unassigned)


(Blocks 1 open bug)


MS Outlook already sends these headers:
Accept-Language: de-DE, en-US
Content-Language: de-DE

I think we should add "Content-Language" to our messages.
We should also set the spell checking dictionary to the language of the message being replied to. We can also use this header when restoring a saved draft, that is, most likely, bug 1169184 can be fixed as part of this.

See also bug 1020181.
I don't think that belongs in a header. For html mails it should be set for the <html> element, and for messages with mixed parts each part should of course be tagged separately.
At least for single part plain text messages it makes good sense.
Anyway, we can discuss where to store it.
Looking at bug 1228193 where someone complained that to set the default font for UTF-8 encoded messages you need to set the font for "Other Writing Systems", which isn't obvious, we could do better if we had language information for plain text e-mail in the header. If we populated the root element of the viewed document/e-mail with the language, then according to bug 1228193 comment #10, Gecko would pick the corresponding writing system.
Blocks: 1228193
Blocks: 1169184
In bug 1169184 the Content-Language header according to RFC 3282 was implemented. This is now sent out with every message.

So I'm changing the summary to what is left to do. Maybe the rest of the bug here is a WONTFIX since Magnus pointed out that the Content-Language received from MS Outlook is unreliable; it transmits the installation language and not the language of the e-mail. See bug 1169184 comment #6 and

Maybe we leave the use of the Content-Language to add-ons. There are add-ons which automatically set the language for a composition, so they can use the additional information:
Summary: Communicate content language of e-mail and reply to e-mail with the correct dictionary set → Reply to e-mail with the correct dictionary set (based on Content-Language header)
Now that bug 1169184 was fixed by storing the current message/spell checking language in a Content-Language header.

We use that header for internal purposes, but then ultimately it is sent out with the outgoing message.
It was said that Outlook produces the header too, but does not guarantee the correctness of the value. It sends out the installation language, not the spelling language or any other setting of the user (who knows in which language he has written the particular message).
It appeared to me, in TB we also do not guarantee the correctness of this value in current implementation. It does not store the TB localization (as in Outlook), but the current spelling language. But that also fails for users that do not use the spellchecker often. In that case, we store the default spelling language, which may or may not be the language in which the current message is written.

Can we decide in this bug whether we really need to send out this Content-Language header when it will again be incorrect?

I see several options here:
1. Do not send out the header ever.
2. Send it out only when we are reasonably sure the user has decided this is the correct language (e.g. by switching dictionaries manually, or operating the spell checking dialog).
3. Send it out when we could determine the language properly automatically. This option is very hard and not easily doable.
Actually, I'm a great friend of RFC 3282. I would *always* send the header. Too bad that there is software and users that don't get it right. But why abolish knives since they not only cut bread ;-) ?

So I'm against option 1. If we didn't want to send the header, we could have stored the language in the draft info header. Option 2 is also not feasible. Say there is a one-language user that always writes in English. He never switches dictionaries and doesn't use the spellcheck dialogue. Why should he not send out that setting with is 100% correct?

IMHO, what I have done in bug 1169184 is 100% right and necessary. Now the question is, how to use the unreliable information on the other side. I could imagine a prompt: Language found, do you want to use it? Or a preference, or a status display. Or we do nothing and let add-ons worry about it.
Maybe send the header only if there are less than, say 10% (maybe configurable) misspelling? 
And if dictionaries isn't used, also skip it as we really can't say. Especially for en-US installations, you might easily use that to get system consistency but write all your content in your own language.
(In reply to Magnus Melin from comment #7)
> And if dictionaries isn't used, also skip it as we really can't say.
You mean, no inline spell checking used?
Yes. I imagine most people have it on.
You need to log in before you can comment on or make changes to this bug.