57440 - Make default mail folder names localizable

Status: VERIFIED FIXED

(MailNews Core :: Localization, defect, P2)

Description

[Karl Ove Hufthammer]

In the mailnews tree, the localized names of special folder (Inbox, Trash &c.)
are displayed but in the message filters and e-mail and news settings, they're
not. Example:

In 'Copies and Folders' you can choose where to place a copy of outgoing
messages. Here, the names of the special folders are called 'Sent', 'Draft' and
'Templates', and the localized names aren't use. The same goes for the message
filters 'Move to' option.

Comment 1

[Karl Ove Hufthammer]

Correction: Localized folder names for special folders are *aren't* being
displayed in the 'Messenger Folders' list either.

(The reason why I sais they were, is that I imported some folders from (a
localized) Outlook Express, and the (localized) names given to the folders there
were being used.)

Comment 2

[rchen]

Which properties file or dtd? 

Comment 3

[Karl Ove Hufthammer]

The strings are contained in 'messenger.properties' but aren't being used.

Comment 4

[rchen]

There are some reasons we don't localize them. Momoi, am I right? You can 
explain better. Reassigned to momoi.

Comment 5

[Katsuhiko Momoi]

I believe that this is a core bug.
Ideally we should be able to localize these names.
However, doing that takes more than a little work
since these default folders are used for various
internal operations. This is the reason why NS L10n
team did not press on it so far.

I think this is going to miss the RTM for NS6, but
it would be a good idea for the mail team to assess
hoe much work it would take to be able to localize
default folder names and at the same time not have
any operations involving these default fodlers to fail.

I'm going to send this over to mscott first. Please
re-assign as needed.

Comment 6

[Katsuhiko Momoi]

Sending it so [e-mail].

Comment 7

[Karl Ove Hufthammer]

> I believe that this is a core bug.
> Ideally we should be able to localize these names.
> However, doing that takes more than a little work
> since these default folders are used for various
> internal operations.

Of course, internal names should be completely separate from external 
(displayed) names.

> This is the reason why NS L10n
> team did not press on it so far.
>
> I think this is going to miss the RTM for NS6,

Well, I'm only interested in localizing Mozilla, so I can wait ... :)

> but
> it would be a good idea for the mail team to assess
> hoe much work it would take to be able to localize
> default folder names and at the same time not have
> any operations involving these default fodlers to fail.

I remember these were localizable before (I'm not 100% positive, but I think 
so).

Comment 8

[Alec Flett]

I did a fair amount of work to make these localizable... I'm not sure what went
wrong. the values are in messenger.properties, as
sentFolderName/draftsFolderName/etc...

I think the problem is that either the datasource has busted and is returning
the internal names, or the rdf <template>s are requesting the wrong name of the
folder

Comment 9

[Katsuhiko Momoi]

We had a problem with finding POP mail folders like Inbox, i.e.
Inbox will not load at all, when default folder names like Inbox
were localized. In the NS-internal Bug database #1823
, we describe the problem caused by localizing these folders.
We don't have a problem with IMAP folder names as these are
stored using UTF-7 (modified) locally.

We also discussed this same issue in Bug 14421 and both sspitzer and alecf
commented there. As I stated in Bug 14421, in principle even
default folder names should be localizable. We just might not have
sound foundation to support that desirable results even if the
strings become localizable again. But this should be something we
can work on post-6.0.

Sending to alecf since he seemed to have worked on this issue
last.

Comment 10

[scottputterman]

reassigning to putterman. Alec isn't working on mail anymore.

Comment 11

[Alec Flett]

btw, we do have a pretty sound foundation for this - I actually think this might 
just be a display issue - the foldernames on disk might be the actual localized 
names...

Comment 12

[Karl Ove Hufthammer]

Of course folder names should be localizable. *But*, their internal 
representation (e.g. their file names) should *not* be. It should be a clear 
separation of underlying names and the displayed names (just like the 'To' 
and 'From' lines are translated when viewing e-mails, but sent as 'To' 
and 'From').

Comment 13

[Alec Flett]

There's no reason why the foldername on disk, and the folder name in the URI,
can't match the foldername displayed to the user. In fact, it would probably be
nicer if they matched, just so that users could recognize them on disk in case
they wanted to back them up by hand, etc... The only required difference between
the displayed name and the on-disk name is the encoding.

Comment 14

[Karl Ove Hufthammer]

>There's no reason why the foldername on disk, and the folder name in
>the URI, can't match the foldername displayed to the user. In fact,
>it would probably be nicer if they matched, just so that users could
>recognize them on disk in case they wanted to back them up by hand,
>etc...

I disagree. This would make it harder to keep track of "special" folders. There 
would need to be a mapping between disk folder name and what that folder "is". 
Other e-mail programs providing a Mozilla e-mail import feature would have to 
check with a separate file what the names of the special folders is (most 
probably won't, and would therefore only work with the English localization.

And what would happen if the user changes to another language (pack)?

Comment 15

[Alec Flett]

- we already use mork (.msf) files to determine the Sent/etc status - we've
never relied on the on-disk name
- changing language packs does not matter - the folder is created and then
"flagged" at runtime.

If you're interested in persuing this, I suggest you learn a bit more about our
architecture - start with the big picture
(http://www.mozilla.org/mailnews/arch/) and then start reading the code
(http://lxr.mozilla.org/seamonkey/source/mailnews)

Comment 16

[Karl Ove Hufthammer]

> - we already use mork (.msf) files to determine the
> Sent/etc status - we've never relied on the on-disk name

OK, that's good.

> - changing language packs does not matter - the folder is
> created and then "flagged" at runtime.

What I meant is that the name of the file doesn't change when you change 
language pack (or does it?). If it doesn't, we can't use the file name as 
display name.

Comment 17

[scottputterman]

nominating as mail3 and reassigning to sspitzer

Comment 18

[scottputterman]

marking nsbeta1+ and moving to mozilla0.8

Comment 19

[scottputterman]

reassigning to naving.

Comment 20

[Navin Gupta]

Take the case of local folders they are created with the on-disk name.
So I think we should have the same display name and on-disk name 

Comment 21

[Karl Ove Hufthammer]

> Take the case of local folders they are
> created with the on-disk name.
> So I think we should have the same display name and on-disk name

Do you mean that the on-disk name (file name) should change when the user
installs a new language pack, then?

Comment 22

[(not reading, please use [e-mail] instead)]

Here's what'd I'd suggest:

for local folders, the name on disk should always be ASCII (like "Sent"), the
internal uri would be ASCII (like "mailbox://nobody@Local Folders/Sent") and the
displayed name should localized.  ASCII file names will always work.  

We should not change the folders on disk based on the language pack.

We already have nsMsgLocalMailFolder::GetPrettyName().  Check if the folder
flags there, and if it is a special folder, return the appropriate localized
name (from the string bundle).  

Be efficient and only retrieve the localized names for the special folders once
from the string bundle.

comments?

Comment 23

[scottputterman]

I agree with sspitzer's last comments.  Navin and I were talking about this the
other day and it seems that if we localize the names on disk that we have
scenarios where we run into trouble.  Having a common name across all releases
on disk means that someone could install different localized versions on the
same machine and have everything work fine.

Comment 24

[scottputterman]

moving to mozilla0.9.  We need to do further evaluation about how hard this will
be and how much risk it will be to the code to get this right.

Comment 25

[scottputterman]

marking nsbeta1- and moving to future milestone. It looks like this will be
pretty risky to do.

Comment 26

[Teruko Kobayashi]

Changed QA contact to [e-mail].

Comment 27

[Michele Carlson]

jenm - can you respond to scott's message? this needs to be fixed because folder
names appear in english rather than the localized languages. Bad for the user to
see/use.

Comment 28

[Andreas Becker]

changing QA contact to [e-mail].

Comment 29

[Jaime Rodriguez, Jr.]

Scott - Can you clean the Status Whiteboard? It conflicts with the nsbeta1- you
have given this bug.

Comment 30

[scottputterman]

the status whiteboard indicatees to me that we cut an nsbeta1+ bug on 2/13. The
keyword and target milestone show it's current state.

Comment 31

[Jaime Rodriguez, Jr.]

ah, maybe i read it wrong the first time. thought u saw [nsbeta1+ 2/13]

Comment 32

[ji]

Due to this problem, the localizer is unable to localize the default mail folder
names. Considering the default mail folder names are localizable at 4.7x and a
lot of complaints and bugs from outside localizer, we need to set an appropriate
milestone for this.

Comment 33

[scottputterman]

It's going to be at least a few milestones away, hence the future.

Comment 34

[Jaime Rodriguez, Jr.]

Jenm/Roberts - Nominating for TM0.9.4. Request from CompuServe DE.

Comment 35

[Cindy Roberts]

Marking nsbranch- as it was decided in the August bug triage that we wouldn't
have eenough time in eMojo to fix this.  Let's revisit for MachV.

Comment 36

[Scott MacGregor]

cleaning up nsbranch keywords. 

Comment 37

[xspuente]

I'm localizing Mozilla to Asturian, and my opinion is that the name of the
folders should be localizable, but the name of the on-disk files or folders
should be kept in English. That's much better than keeping everything in
English, because most of the people won't look at the saved folder, and most of
the programs will find the folders in order to import emails. This will allow to
change language and keep all your email folders with your messages, but the name
of the folders will be localized in the UI.

It's almost one year since this bug started, and I think that keeping the
on-disk folder name in English is less worse than keeping the UI in English
(that for many people doesn't mean anything).

Xose

Comment 38

[ji]

Nominating for nsbeta1.

Comment 39

[Michele Carlson]

These folders really need to be localizable. navin - do you have a status? 
Right now we have to keep the folder names in English in our localized builds.
It doesn't look good to our int'l customers. 

Comment 40

[Navin Gupta]

I will not be working on this anytime soon. Next 2 milestones are for footprint
and performance related issues only.

Comment 41

[danielmc]

Nominating Mach V.

Comment 42

[scottputterman]

Please don't touch target milestones.  Add an nsbeta1 to the keywords if you
want to nominate this.  As you can see, the nsbeta1+ means that we are currently
planning on doing this.  I haven't scheduled it yet.

Comment 43

[danielmc]

Sorry - my bad.

Comment 44

[scottputterman]

reassigning to cavin.

Comment 45

[ji]

This is really a annoying problem when migrating from localized previous
versions, like from Simplified Chinese Communicator 4.51. After migration, since
we can't localize the default mail folder names in mozilla, the user will have
two sets of default mail folders, one is in English and the other one is in
localized language. And the old mails (before migration) will be kept in old
localized default mail folders. The user has to switch mail boxes after
migration to read his/her old mails in Inbox, Sent, Draft....

Comment 46

[Michael Buckland]

Discussed at 2/19/02 bug meeting w/ Eng/PjctMg/Marketing: decided to move to
1.2, and change nsbeta+ to nsbeta-

Comment 47

[Michael Buckland]

Making depend on 122274

Comment 48

[msanz]

renominating; please involve IQA (Andreas Becker) when you triage this bug, they
have input that can explain why it's needed. We are planning on some
localization work and this will be a very nasty bug in future versions

Comment 49

[Michael Buckland]

Fixing dependecy which I mis-entered on 2/20

Comment 50

[ji]

International group has renominated this. Please see comments #48.
Removed dependency on bug 122274 for now.

Comment 51

[Michael Buckland]

Need input from Andreas.  I have the action item to invite him to 2/26 bug
triage meeting at 2pm.

Comment 52

[scottputterman]

reassigning to naving.

Comment 53

[Navin Gupta]

Attachment: proposed fix

The general idea is to have a prettyName or displayName that will use the
localized names for default folders. We already have prettyName attribute
on nsIFolder and I'm using that. So when we are discovering imap/local folders
we look for a special folder and set the prettyname if it is a special folder. 

If you look at localFolder, I'm setting in a few places because "Empty trash"
creates new trash folder and when we create new pop/local accts we set the flag

on default mailboxes, so prettyName has to be set. For imap when we are
synching
folders with the imap server, then also we need to set the prettyName. imap
subscribe part had to be changed because it was showing all server folder names

so I had to get the prettyName for default special folders to show them in the 

UI. Now when the user changes subscribe setting for any folder, we need to
convert the localized name to our "internal names" and send them to server. 

I also removed some confusing comments about getting string bundles for well
known "internal names" like INBOX, Sent....and also removed string bundle stuff

from pop3IncomingServer - never used. 

Testing..
I have tested existing pop, imap, new pop, imap and migrated pop, imap accts
also webmail and aol have been tested. Common operations like receiving,sending

deleteing and copying mail, all have been tested, Saving to drafts & templates,

Send later have been tested, All ui's where folder names appear like menus, 
offline selection search/filter , new folder ui have been tested. also 
tested cyrus imap server and everything looks good. Next msg navigation also
shows special localized names, I will continue to look for more things. 

david, need review.

Comment 54

[Navin Gupta]

cc bienvenu for review

Comment 55

[David :Bienvenu]

+PRUnichar *nsImapIncomingServer::kInboxName = 0;
+PRUnichar *nsImapIncomingServer::kTrashName = 0;
+PRUnichar *nsImapIncomingServer::kSentName = 0;
+PRUnichar *nsImapIncomingServer::kDraftsName = 0;
+PRUnichar *nsImapIncomingServer::kTemplatesName = 0;
+PRUnichar *nsImapIncomingServer::kUnsentName = 0;

no need to initialize these to 0; they're globals, so they'll be initialized by
the linker.

I think these variables should have better names to help avoid confusion.
Something like kLocalizedTrashName or kLocalizedInboxName; I think this would
help avoid people using them thinking that they're equivalent to "Trash" or "Inbox".

Re the whole imap subscribe stuff - I'd be just as happy if we didn't show those
names localized in the subscribe ui and it would cut down on the diffs
considerably. The rationale is that the subscribe UI is a power user feature,
and power users would probably rather know what the folders were really called
on the server, kinda like what the folders are really called on disk. Opinions?

Comment 56

[Navin Gupta]

I will change the names to kLocalizedInboxName... after we know, what we are
doing with subscribeUI. 

Comment 57

[scottputterman]

I'm not sure about the subscribe dialog.  My initial feeling is that it should
show whatever is shown in the folder pane.  However, it sounds like not doing
this would cut down on risk so since this is a very advanced feature, I'd be
fine without making the changes to IMAP subscribe.

Comment 58

[David :Bienvenu]

the subscribe ui is the only way for users to know what's going on on the
server, and I'm uncomfortable lying about what the folders are called everywhere
without having some sort of "out".

Comment 59

[scottputterman]

I think that's fine.  If we get feedback to suggest otherwise, we can add it to
subscribe later.

Comment 60

[Navin Gupta]

My preference was to show it just like folder pane. I have tested it and it looks
ok, but seeing previous two comments -looks like a decision has been made. 
I'll attach a new patch. 

Comment 61

[Navin Gupta]

Attachment: proposed fix

removed the imap subscribe part and changed names to 'localized'

Comment 62

[David :Bienvenu]

Comment on attachment 72473 [details] [diff] [review]
proposed fix

r=bienvenu, except I'm wondering why you're checking both the folder flags AND
the name before setting the pretty name. Is there some case where this makes a
difference? Why not trust the folder flags? Is it in case we have multiple
folders with that flag set? Or are you just being extra careful?

Comment 63

[Navin Gupta]

Comment on attachment 72473 [details] [diff] [review]
proposed fix

this has sr=sspitzer once
I add back //Notice no inbox
comment. 

David, A user can have 
a sent folder not the
default folder "Sent", 
so we don't want to set 
the localized name in that
case.

Comment 64

[Asa Dotzler [:asa]]

Comment on attachment 72473 [details] [diff] [review]
proposed fix

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 65

[David :Bienvenu]

ah, thanks, makes sense.

Comment 66

[Navin Gupta]

fixed

Comment 67

[(not reading, please use [e-mail] instead)]

it was wise of naving/bienvennu to spin off the subscribe UI part of this.

I think that there might be a simple fix for that issue.

I think we can do this:

the subscribe datasource will call 
nsSubscribableServer::GetLeafName(const char *path, PRUnichar **aLeafName) 
to determine the pretty name to show in the subscribe UI.

in ::GetLeafName() I think we could build up the folder uri (using path) and
then use the msg folder datasource to get the resource for that uri, and then QI
to nsIMsgFolder and then get the pretty name attribute, and return that.

we should spin up a new about about how the subscribe UI does not match the
folder pane UI, and try this approach first.

Comment 68

[ji]

Since there is no localized build yet to verify the fix, I'm thinking to change
the folder names in a US build to see if it still works or not. Navin, which
strings (in messenger.property?)should I change to make fake localized folder
names? 

Comment 69

[Navin Gupta]

yes, in messenger.properties change these strings 

# LOCALIZATION NOTES (inboxFolderName): DO NOT TRANSLATE (bugzilla #64199)
inboxFolderName=Inbox
# LOCALIZATION NOTES (trashFolderName): DO NOT TRANSLATE (bugzilla #64199)
trashFolderName=Trash
# LOCALIZATION NOTES (sentFolderName): DO NOT TRANSLATE (bugzilla #64199)
sentFolderName=Sent
# LOCALIZATION NOTES (draftsFolderName): DO NOT TRANSLATE (bugzilla #64199)
draftsFolderName=Drafts
# LOCALIZATION NOTES (templatesFolderName): DO NOT TRANSLATE (bugzilla #23625).
# Fix to bug 23625 requires to create template folder URI for new IMAP account, 
# which requires the folder name to be picked from here like for other special
folders
templatesFolderName=Templates
# LOCALIZATION NOTES (unsentFolderName): DO NOT TRANSLATE (bugzilla #64199)
unsentFolderName=Unsent Messages

Comment 70

[(not reading, please use [e-mail] instead)]

I've spun the subscribe issue off to http://bugzilla.mozilla.org/show_bug.cgi?
id=129141

Comment 71

[Marek Wawoczny]

Seems that in IMAP some strings are still not changed to localized strings (for example when getting new mail in status bar I've got INBOX instead of localized string), see screenshoot.

Comment 72

[Marek Wawoczny]

Attachment: Screenshot of status bar

Comment 73

[ji]

Marek, I think we need to file a seperate bug for the status bar problem. Could
you do this? Or do you want me to file this? Please let me know. Thanks.

Comment 74

[Marek Wawoczny]

Ok, will do it :)

Comment 75

[Marek Wawoczny]

IMAP Status bar bug: http://bugzilla.mozilla.org/show_bug.cgi?id=129530

Comment 76

[ji]

Marek, thanks for filing the bug.
After you localized those default mail folder names, are you able to connect to
the server using POP? I'm asking this because I don't have a real localized
build to verify this yet, maybe your experience can provide more info about the
bugfix verification.

Comment 77

[Marek Wawoczny]

POP:
Getting messages - ok...
Sending messages - ok...
Saving drafts - ok...
Saving templates - ok...
Deleting - ok...

IMAP:
Getting messages - ok...
Sending messages - ok...
Saving drafts - not working, probably because I don't have Drafts folder...
Saving templates - not working, probably because I don't have Templates folder...
Deleting - ok...

So in summary everything seems fine :)))

Comment 78

[ji]

Thanks a lot, Marek. I'll leave this as "resolved" until I have a localized
build to verify.

Comment 79

[xspuente]

Did you create the account with the localized strings. Because when I first
reported this problem, I could create an email account (POP), but then Mozilla
wouldn't ask me for the password, and it wouldn't connect to the server. If I
swichted to English, it worked. And after the first time in English, I could go
back to Asturian, and everything worked fine afterwards.
So, can you install Mozilla and apply a langpack or a localize the strings
BEFORE you set up an email account, and verify that you can get mails?

Comment 80

[Marek Wawoczny]

It works with:
- Existing account (en-US and after swithing langpack with localized names)
- New account (en-US and after swithing langpack with localized names)

So it works for me in any combination

Comment 81

[Marek Wawoczny]

> Thanks a lot, Marek. I'll leave this as "resolved" until I have a localized
> build to verify.

I can send You pl-PL langpacks or whole Windows build.

Comment 82

[xspuente]

Hi Marek, let me explain my initial problem again. The localized strings worked
always if you created the account with en-US, and then you switched to your
locale. However, the expected behaviour is that you can have your locale and
create an account in that locale without switching to en-US to create, and then
back to your locale.

To be more precise:
- I installed Mozilla en-US and applied Asturian langpack. Everything works fine
with that locale.
- I set up an email account, and everything looks fine, but then it doesn't
connect to the server.
- I switched to en-US, go to Mail and News, and connect, enter my password, and
works.
- Then I switched again to ast, go to Mail and News and it worked.
It looked to me that the English strings were necessary to start the account,
and then it would work with the localized ones. If you can apply a langpack and
then set up an account in that language (or with the localized strings) that
would answer my question.

Comment 83

[Marek Wawoczny]

> It looked to me that the English strings were necessary to start the account,
> and then it would work with the localized ones. If you can apply a langpack and
> then set up an account in that language (or with the localized strings) that
> would answer my question.

Account could be created with localized build (for example in pl-PL), then it
works with localized build and with original en-US. I had no problems with that.

Comment 84

[Robert Kaiser]

if this can be verified, then bug 81914 should be marked FIXED as well as it is
about get pop msgs not working with localized mail folder names, and that is
fixed with this patch, too :)

Comment 85

[xspuente]

Is this bug really fixed? I've checked the latest build (at 03/21/2002) and the
Localization Notes preventing Inbox,... localization remain there.

Comment 86

[ji]

We need to remove the l10n notes. I'll file a bug.

Comment 87

[ji]

Filed bug 132826 to remove the l10n notes.

Comment 88

[ji]

Verified as fixed with a Ja build.