694556 - Spell-checker and Content-Language header field

Status: RESOLVED DUPLICATE of bug 967494

(Thunderbird :: Message Compose Window, defect)

Description

[Alessandro Vesely]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Build ID: 20110928134238

Steps to reproduce:

I was writing a message, and the spell-checker was set to "English".


Actual results:

Someone called by phone, prompting me to write a message.  I did it right away, yes: TB allows to compose two messages at the same time.  However, in order to avoid lots of errors, I had to change the setting of the spell-checker (which can be done from the compose window).  When I resumed writing the previous message, the spell-checker was using the wrong language.


Expected results:

Each message should have a Content-Language header field, as specified by RFC 3282.  The spell checker should initially set it according to its settings, so as to remember what language each message is being composed in.

Comment 1

[Jo Hermans]

Should be bug 338427 (which is already fixed in the development version), although I don't know if it would apply to a message that you're still writing.

Comment 2

[Alessandro Vesely]

(In reply to Jo Hermans from comment #1)
> Should be bug 338427 (which is already fixed in the development version)

Hence the required machinery is already in place.  However, bug 338427 is about the Firefox browser (and complicated because of the many places where web pages can store language info.)

Thunderbird currently sets Content-Type and Content-Transfer-Encoding, but not Content-Language.  The latter header field should be added in messages being composed, with a value valid for Get/SetCurrentDictionary() calls.  This field should then be sent along with the outgoing message, or saved draft, so that it's always available when editing a message as new, and may possibly serve some other purposes as well.

Comment 3

[Jo Hermans]

(In reply to Alessandro Vesely from comment #2)
> Hence the required machinery is already in place.  However, bug 338427 is
> about the Firefox browser (and complicated because of the many places where
> web pages can store language info.)

No, it's not. It applies to all applications based on Gecko.

Comment 4

[Alessandro Vesely]

(In reply to Jo Hermans from comment #3)
> (In reply to Alessandro Vesely from comment #2)
> > Hence the required machinery is already in place.  However, bug 338427 is
> > about the Firefox browser
> 
> No, it's not. It applies to all applications based on Gecko.

I'm not overly familiar with TB architecture, but setting an email message header field is not an operation that "all applications based on Gecko" can do.  Firefox, for example, does not send email messages, and hence cannot set email message header fields.

Comment 5

[Jo Hermans]

I repeat : bug 338427 is the core-level support for selecting a dictionary based on lang-element. That's in the DOM tree. It doesn't say how the element is brought into the DOM tree, that's the job of the application.

Composing a message is different, since you would select a dictionary with the spelling-popup (due to bug 338427 it might be possible to set the language in the DOM tree directly, and select the dictionary based on that, but I don't think it would make a difference). And it still doesn't set the Content-Language header in the message anyway. Didn't find a bug for that though.

But more interesting is when you're replying to a message : the language could be selected based on the Content-Language header in the original message. The current code doesn't do it at all - the spelling popup is used to select the language (once, for the entire app), and it has nothing to do with a possible email-header.

Bug 142092 seems to be related to the parsing of the Content-Language header, although it's only used to select 1 body part from a multipart/alternative MIME message, if you have a preference for one of them.

Comment 6

[Alessandro Vesely]

(In reply to Jo Hermans from comment #5)
> And it still doesn't set the Content-Language header in the message anyway.
> Didn't find a bug for that though.

That's why I filed _this_ bug: to add a Content-Language field in message headers.

N.B. According to the "Security Considerations" section of RFC 3282, it should be possible for concerned users to avoid setting such header field, as it
  "may be used to infer the nationality of the sender,
   and thus identify potential targets for surveillance."

Comment 7

[Thomas D. (:thomas8)]

Alessandro, thanks for filing and defending your user story wrt TB composition and spell check. You are very correct on the symptoms of this bug: With two or more simultaneous compositions, there's a wrong design that the spell check language choice gets shared and applied between all open compositions.

I can't comment if your proposed solution is technically suitable or not.
Suppose it's better to keep problem description and proposed technical solutions apart and let the experts make the call.

These things are complex in their interactions hence tricky to fix and we're working on limited volunteer manpower resources. Sorry if that can cause bugs like this to remain unattended.

To support your cause and move this forward, I'll make this a dupe of more recent bug 1059835 which comes with more precise steps for reproduction.

Comment 8

[Thomas D. (:thomas8)]

Fix pending in bug 967494.