Closed Bug 3966 Opened 25 years ago Closed 25 years ago

Mail- Charset menu needs to set a mail folder charset

Categories

(MailNews Core :: Internationalization, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: nhottanscp, Assigned: scottputterman)

References

Details

(Whiteboard: DEPEND - Intl)

Separated from #2341.
The initial value for a mail folder charset to be taken from a pref (see #3965).
The mail foder charset vaule should change by the charset menu.
AppCore has the code for the charset menu change, we need to notify this change
to msgdb.
Status: NEW → ASSIGNED
Target Milestone: M4
Summary: Charset menu needs to set a mail folder charset → Mail- Charset menu needs to set a mail folder charset
Assignee: nhotta → bienvenu
Status: ASSIGNED → NEW
Reassigning to bienvenu. Please use a pref "intl.charactesr_set_name" as a
default charset value, use "us-ascii" if the pref is not specified. If that's
done then reassing back to me. I need to do charset menu and charset mapping
(e.g. Shift_JIS to ISO-2022-JP) change.
Status: NEW → ASSIGNED
Are you saying that the low-level db code should always write out the value of
the pref, if not empty, and us-ascii if empty? Or are you saying it should
return this value if not in the database? Shouldn't it be the job of the code
creating the database to set the charset with this policy? In the past, the
database code has not dealt with preferences at all. My plan is to just add the
api to get and set the charset and various database clients can decide what they
want to do with the charset.
I think get and set API is the right way. The user of the db should decide the
charset (get default from pref, update it via charset menu).
Please add the API and it's a separate task for the db user to actually use the
API to set a charset.
In the case of the thread pane, who is the user of the db API?
the mail folder data source is the client, which Scott Putterman is working on.
the mail folder data source is the client, which Scott Putterman is working on.
the mail folder data source is the client, which Scott Putterman is working on.
This may be move to M5 but we need the status update.
Is the db API available? How about the mail folder data source?
Charset menu has not been done but it requires above two task to be done.
neither the datasource or the folder is currently managing the character set.
Assignee: bienvenu → putterman
Status: ASSIGNED → NEW
the db api is checked in - I'll re-assign to scott for now.
Status: NEW → ASSIGNED
Target Milestone: M4 → M5
I'm moving this to M5.
Target Milestone: M5 → M6
This can wait until M6.
This is needed in order to view non MIME labeled headers (e.g. 8bit European),
bug#5660.
In addition to set charset through UI to db, there is a minor request of a
change to the msgdb. When msgdb calls DecodeMimePartIIStr, pass the folder
charset to the decoder so it can do the conversion (to unicode) in case the
header is not labeled.
Target Milestone: M6 → M7
reassigning to M7
Whiteboard: DEPEND - Intl
Blocks: 7228
I just wanted to update this bug.  Last week I made it so that changing the
charset using the menu makes the folder change it's charset.  At the moment, I
don't think the db is saving this off - I'll need bienvenu's help with this.
Also, switching to a folder isn't making the window take on the charset for that
folder yet.
Blocks: 5660
Let me restate what I last wrote.  I don't think the db is saving this value off
so I don't think the headers are coming back with the correct charset.  I
also don't currently have any way of changing the charset menu when a new folder
is loaded.    I have written a GetCharset function for the folder which returns
the charset for that folder, or if there is none, the value of the
aforementioned preference (or "us-ascii" if there is none).
nsIDBFolderInfo has methods to get and set the charset, e.g., SetCharacterSet,
which I believe does remember the charset string. And nsMsgDBFolder does call
this method. Does this routine not work, or is there something else I need to
do?
I might be doing something wrong when I start up the next time.  I'm calling the
db calls.  It looks like when I start up the next time, the character set isn't
being remembered.  I'll look into that again, it's been a week or so since I
last looked at this.
I haven't changed that routine in a long time, so if it was broken a week ago,
it's still broken :-( The Get routine uses a very low level utility and I'd be
surprised if it was broken, but maybe it is. Or perhaps we're not doing a commit
after changing the character set?
I have a fix for this.  What this will do is let you set the character set from
the character set menu.  This will then change the db and save it in the db.

What this won't do:

1.  It won't change the character set menu to have the appropriate character set
with a check mark next to it.

2. It won't reload the message headers.  So if you want to see the new headers,
click a different folder and then click back on the folder you care about.

If this is sufficient I'll mark this fixed and then we can file bugs on the
other parts for later.

Should I be able to see anything on my machine?  My message headers always look
the same regardless of what character set they are.
I made the change suggested by Naoki, but I don't see any difference.
5660 needs to be fixed in order to see the difference (I will try to make it for
M7). It was necessary that this bug to be fixed first then MIME decoder can rely
on the charset input.
I think this bug can be marked as fixed and verification can be done with 5660.
Also remaining issues Scott mentioned should be filed as separately.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Ok. I'm going to mark this as fixed.  I filed 8204 and 8206 on the other
problems mentioned here.
I had to re-open 5660 and so let me hold off verifying this one until 5660 is settled.
Status: RESOLVED → VERIFIED
I was finally able to verify 5660.
I'm now marking this one verified also.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.