User-Agent: Mozilla/5.0 (X11; U; Linux i686; pl; rv:220.127.116.11) Gecko/2008120112 Firefox/3.0.4 Flock/2.0.2 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9.1b3pre) Gecko/20081201 Thunderbird/3.0b1 With tb3beta1(build1) I see untranslated Drafts, Junk, Sent, Templates folder names for new accounts/enabled folders before (first) application restart. All folders should have pretty names right after creation, just like Inbox and Trash. Tested with tb3b1 build1 linux (polish) version¹ however this was also reported earlier as a part of Aviary.pl bug 1980² for win build Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.1b2pre) Gecko/20081101 Shredder/3.0b1pre 1 - downloaded from http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/3.0b1-candidates/build1/ 2 - http://bugs.aviary.pl/show_bug.cgi?id=1980 Reproducible: Always
Given in bug 467528 you say you need a connection to get localized folder names, how is that different to this bug?
(In reply to comment #1) > Given in bug 467528 you say you need a connection to get localized folder > names, how is that different to this bug? Bug 467528 is about offline IMAP only, this one is valid for pop3/local folders and has nothing to do (afaik) with connection state.
(In reply to comment #2) Additionally 467528 affects also inbox and trash, this one not.
(In reply to comment #0) > All folders should have pretty names right after creation, just like Inbo x and Trash. (In reply to comment #2) > this one is valid for pop3/local folders To Stefan Plewako(bug opener): How did you create the folders? Created "Drafts", "Junk", "Sent", and "Templates" manually with specifying folder name of non-localized version(==same as folder file name)? Or, Tb created these folders upon your action such as "Save As Draft"?
(In reply to comment #4) > Or, Tb created these folders upon your action such as "Save As Draft"? After enabling junk filtering in account prefs, saving mail as draft or template and sending message. All folders created by tb after above actions.
Same phenomenon was observed with Japanese Tb 18.104.22.168 on MS Win-XP SP3, with newly defined POP3 account(Drafts/Junk/Sent/Templates are not created upon account definition since a Tb version), and with manual creation of mail folder named "Drafts", "Junk", "Sent", "Templates" at the POP3 account. "Localized name" was not displayed until restart of Tb. Adding "Local mail folder" in bug summary, in order to isolate this bug from Bug 467528 on localized name of IMAP mail folder.
To David Bienvenu: Similar regression to Bug 450754/Bug 467528 on "localized local mail folder name" by Bug 413721?
WADA, please do not test this in Thunderbird 22.214.171.124, as this is not really helpful anymore. Please only test this on the Thunderbird 3 beta 1 release candidates that Stephan is using.
it may be a similar regression, but the cause must be completely different, since bug 450754's cause was imap-only.
With bug 450754/bug 467528 fixed nightly I'm not sure if this bug is affecting local accounts only. (don't have good imap repro steps yet)
Stefan: but you still see it on trunk?
(In reply to comment #11) > Stefan: but you still see it on trunk? Yes, Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9.1b3pre) Gecko/20081215 Shredder/3.0b2pre
(In reply to comment #10) > With bug 450754/bug 467528 fixed nightly I'm not sure if this bug is affecting > local accounts only. (don't have good imap repro steps yet) OK, affecting also IMAP, repro steps: 1. Create fresh profile 2. Choose "Gmail IMAP" in account wizard and configure it 3. Connect to server to download folder list (important) 4. Enable junk filtering for gmail account (with defaults selected) 4.a "Junk" folder should be created immediately 5. Restart Thunderbird 5.a "Junk" folder name will be replaced with localized one
Hah, very similar bug 273422 found - reported for 1.0rc, different locales (de, sv-SE) and global inbox only.
This blocks a credible l10n release. Setting an arbitrary milestone. b2 won't happen if no one jumps in.
+ Archives folder (per bug 473529#c8)
Joey, do you have any time to look at this?
Assigning to jminta for now, as per IM discussion.
Just for fun I looked into this a little. The issues are not in the js, but buried in the C++ folder code. folderPane.js is just using "this._folder.abbreviatedName" which should simply work, but doesn't. The initial folder name is set by calls to nsMsgDBFolder::parseURI, which simply uses the tail of the folder URL to get the name - which is not localized. Once set though, the folder name is then cached and not recalculated in the current session. Somehow we need to call SetPrettyName which is where the localization occurs. There are a variety of ways the problem might be solved, and I am still investigating the best approach. But in theory this is not a difficult problem to solve.
I spoke too soon about the "not difficult" thing. Tracing out in some detail the issues with localizing the Sent folder, a problem is that the folder is initially created and displayed without getting the SentMail folder flag set. At least on local folders, that does not appear to get set until restart. The normal routine that adds localization, SetPrettyName, will only localize if the flag is set. I know in at least some places in the UI (IIRC for junk) TB will set the folder flags correctly based on how the folder is actually used, for example where the account manager says certain classes of messages are supposed to go. But at least for local folders, on restart it will stupidly set the folder flag on any folder that matches the default name ("Sent" or "Junk") and then also rename to the localized name. So clearly the easy solution to this will be to follow the lead of LocalFolders, and localize the name in the folder pane (or perhaps in nsMsgDBFolder::GetAbbreviatedName) for any folder that matches the default name for a special folder. This will mean that someone using a non-English locale would be unable to have a folder named "Sent" - it would get automatically displayed in translation. But I think that is already how at least Local Folders behave. If that is acceptable, I could provide the patch to do this. I need at least prior blessing from clarkbw as the "user experience" czar before I will proceed any further. The alternative, which is a much bigger project, is to try to make sure that all folder flags are set correctly based on the actual folder usage, then make sure that the localization works correctly based on the folder flags.
(In reply to comment #21) > But at least for local folders, on restart it will stupidly set the folder flag on any folder > that matches the default name ("Sent" or "Junk") and then also rename to the localized name. When IMAP folder, and when different folder is selected at Copies&Folders, any special folder is changed back to ordinal folder, although restart is needed due to this bug. I've understood why special icon is always set for "local, root level, Sent/Drafts/Templates" and no option to delete is provided.
(In reply to comment #21) > for a special folder. This will mean that someone using a non-English locale > would be unable to have a folder named "Sent" - it would get automatically > displayed in translation. But I think that is already how at least Local > Folders behave. Don't know about the solution, but ^^^ is how it's designed - the default special folders always internally have the English names, i think. That way someone can switch between localizations and still get get nice behavior.
I don't think we'd hold b3 for this; moving out.
Created attachment 391649 [details] [diff] [review] fix archives and drafts/sent/templates/outbox/junk this seems a lot safer to me - just set the flags when we create the folders so that the pretty name stuff will work.
FYI. Bug 497288 is for icon of special folders.
Comment on attachment 391649 [details] [diff] [review] fix archives and drafts/sent/templates/outbox/junk I've just been trying this and it is a lot better. Local Folders works fine with it. There still seems to be an incorrect case for IMAP (with + without the patch). With a fresh profile, I created an IMAP account linking to one of my existing IMAP servers/logins and connected to it straight away. The drafts, archives etc folder names weren't localised. I tried this with and without the patch. The noticeable difference was that with the patch the folders got the special icons straight away, whereas without the patch they didn't - so I think we're heading in the right direction. r/sr=Standard8 as long as we either keep this bug open for the IMAP case, or close it and open a new one.
Bug 508026 spun-off for remaining issue. That'll probably end up blocking as well, but it's good to have very specific bugs...
Mossop points out that this makes the add fcc to replied message's folder feature add the sent flag to that folder. So I need to tweak this to make sure we're using the identity's fcc folder before setting the flag.
Created attachment 392933 [details] [diff] [review] fix fcc to reply folder case this fixes the fcc to reply case. I'd like to get this in soon to avoid nightly users getting too many folders with the sent flag set. We should really figure out a way of cleaning up these flags when set incorrectly...
Patch checked in: http://hg.mozilla.org/comm-central/rev/516661265fc8 (in time the TB nightly).
(In reply to comment #31) > Patch checked in: http://hg.mozilla.org/comm-central/rev/516661265fc8 > > (in time the TB nightly). Thx, Mark!
testing Mozilla/5.0 (X11; U; Linux i686; nl; rv:126.96.36.199pre) Gecko/20090823 Shredder/3.0b4pre Junk is not localized until restart
can you file a separate bug for Junk, and assign it to me, thx.
(In reply to comment #34) > Mozilla/5.0 (X11; U; Linux i686; nl; rv:188.8.131.52pre) Gecko/20090823 > Shredder/3.0b4pre > Junk is not localized until restart (In reply to comment #35) > can you file a separate bug for Junk, and assign it to me, thx. David, do you mean that Junk case is not resolved by patch for this bug? If so, could you please describe about resolved cases and not-resolved cases by patch for this bug, to avoid confusion.
The archive and junk cases are handled in their own specific ways, in different places in the code. The drafts/sent/templates are handled in the same way in the same piece of code. The Junk code looks right to me, but if you say it's not working, then I'll try it in a separate bug.
(In reply to comment #38) > but if you say it's not working, then I'll try it in a separate bug. It's not me. Opener of Bug 513433 said "it's not working with nightly on which patch for this bug is already landed" in comment #34. (See Bug 513433 Comment #5 please). So I asked you about Junk in Comment #37. Sorry but I didn't execute test with localized build or with lang-pack.