Closed Bug 14421 Opened 25 years ago Closed 24 years ago

[I18N] use string bundles in nsPop3IncomingServer.cpp and nsNoIncomingServer.cpp

Categories

(MailNews Core :: Backend, defect, P2)

Product:
MailNews Core
Component:
Backend
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: sspitzer, Assigned: alecf)

References

Details

right now, we are hard coding the names of the default mailboxes:
"Trash", "Inbox", "Sent", etc.
Status: NEW → ASSIGNED
Target Milestone: M12
marking m12, accepting.
Target Milestone: M12 → M13
Target Milestone: M13 → M14
i18n issues move to m14.
Priority: P3 → P2
move to m15
Target Milestone: M14 → M15
moving to m16.  adding bobj to cc list, as it i18n related.
Target Milestone: M15 → M16
cc'd msanz since it's L12Y issue.
Blocks: 14744
adding dependency for 12394
Blocks: 12394
adding tobias to the cc list.  he's going to look into fixing this.
these strings "Inbox", "Sent" are special, as they are on disk as well as in the 
UI, and the UI name comes from the file name on disk.

we don't know if the underlying OS can handle non-ascii file names, so these 
strings may have to remain hard coded.

tobias, if there are strings under mozilla/mailnews/local/src/*.cpp,*.h that are 
only for the UI, those need to put into the "LocalStringBundle".

I need to talk to the i18n folks to see if they agree.

ok, here's how we'll do this.

the name on disk will remain ascii.  but the folder's pretty name will come from
the appropriate string bundle.

(the nsIFolder interface has a wstring prettyName attribute that we will use for
setting the pretty name)

but before tobias can fix this, I need to do some cleanup of
nsLocalMailFolder.cpp and nsPop3IncomingServer.cpp and nsNoIncomingServer.cpp.

I'll do that cleanup today, so he can work on the string bundle part soon.
on second thought, we won't set the pretty name.

the pretty name is stored in the summary file, which means we can lose it.

I'm reading the thread in n.p.m.mail-news about this, and it looks like we will
be able to set the leaf name with a PRUnichar* very soon (with nsIFile).

if it's not ready in time, we can get the nsFileSpec from the nsIFileSpec (using
GetFileSpec) and call SetLeafName() with a nsString& (assuming it has been
fixed, see bug 29543)

tobias, sorry this is such a moving target.
I am working on the nsIFile / nsILocalFile Unicode issue. It is not ready yet. 
It should be ready on 3 platforms earily next week.
Mass moving M16 to M17 - look for nsbeta2 before anything else.
Target Milestone: M16 → M17
giving my i18n bugs to alecf.

thanks alec.
Assignee: sspitzer → alecf
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
alecf, see nsNoIncomingServer::SetFlagsOnDefaultMailboxes() and
nsNoIncomingServer::CreateDefaultMailboxes
nsPop3IncomingServer::SetFlagsOnDefaultMailboxes() and
nsPop3IncomingServer::CreateDefaultMailboxes

all of those have hard coded folder names.
ugh, I just did this in nsPop3IncomingServer and then realized that I had to do 
it all over again in nsNoIncomingServer - I'm going to try to consolidate this 
into nsIMsgLocalMailFolder or at the very least nsIMsgFolder
cool, thanks for consolidating that duplicate code.

(reminder, popincoming has an Inbox, noincoming doesn't)
ok, better fix is in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
momoi - can you verify when time permits?
QA Contact: lchiang → momoi
OK. I'll add this to my list.
localizability issue -- let me pass this on to amasri.
I don't think we are translation these essential mail box names now
but you migh want to consider it. I don't see anything wrong in translating these
mail box names into Japanese.
In any case, this is something we can check with Beta 3.
Work with ji on this, please.
QA Contact: momoi → amasri
I added Japanese file names to messenger.properties. The mail client 
could not handle the changes. Reopening.

Xianglan's comments:
I tried with yesterday's build. 
The new en-US.loc made POP mail account not usable, exactly same problem we saw 
in bug 1832. 
That is: 
 Mailbox names still appear in English, but the server can't find right 
corrsponding mailboxes. 

It looks like we can't use the localized strings for those mailbox names.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Your not supposed to localize the names of folders like Inbox and Trash. We went
through this exercise for PR2 were they were incorrectly localized for japanese
builds. They took that back out. Ji was involved in helping us track that down.
She problably remembers.

In any case, the default folder names are NOT supposed to be localized. re-closing
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Allan, we need to put some notes for vendor asking them leaving those strings in
English, so we won't have the same trouble as we had in PR2.

I agree; let's leave them in English.

Add a release note that reads:

The default files for pop servers must retain their English names: Trash, Inbox, 
Sent, etc. If you rename these files into other languages, Netscape Mail will 
not work correctly
Keywords: relnote3
Oh. I guess I misunderstood Xianglan's comment. She meant localization notes,
not release notes. My mistake. Removing relnotes keyword. But resolution should
probably be WONTFIX, so we wouldn't be tempted to go through this. Marking
verified with the comment that it doesn't really work the way it should.
Status: RESOLVED → VERIFIED
Keywords: relnote3
mscott@netscape.com on 2000-09-21 11:31 said:

> Your not supposed to localize the names of folders like Inbox
> and Trash. We wentthrough this exercise for PR2 were they were
> incorrectly localized for japanese builds. They took that back
> out.

This bug now has been closed but it has relevance to a bug recently
filed. So, let me make some comments on it. Scott, it is true that
we had an internal bug 1823 in which localizing these default
folder names caused POP mail folders to fail to load since these
folders could not found under that condition.

I don't remember if I said this at that time, but in principle
default folder names should be localizable. My assumption is that
we don't happen to have good foundation to realize that goal
right now.
The same issue has been revived in Bug 57440 by Karl Ove Hufthammer.
This issue will keep on surfacing as more people get involved in
localizing Mozilla. So, rather than a quick fix we tried for PR2,
we should get started on a real solution post 6.0.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.