Closed Bug 3966 Opened 26 years ago Closed 26 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: 26 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.