The kids love the "star" feature of gmail, and I think it's a more understandable than "flag" in this day and age. I don't know if gmail always creates a starred folder, or just does it the first time the user stars a mail, but I think we should do the latter. We might want to do something fancy like not do this if a pref is set, and automatically set the pref if the user deletes the "star" folder. We might want to also give the option to the user to create a virtual folder for a tag when the user creates a tag (though we'd need to know which account to do it for). That doesn't handle when they use an existing built-in tag like Important - but we might want to do something similar - create a virtual folder automatically (this might get annoying, so we might want one of those "don't do this anymore/do this automatically" dialogs the first time.

I like this idea.

Let's star with rebranding flag to star first. Arvid is going to replace the flag icons in the next theme update. Then we can think about creating a virtual folder for starred messages. Note: I changed the entity names so localizers will know to update their translations.

step 1 has made its way onto the trunk. Still might change some of the uses of "Star" to "Starred" or vice versa.

Scott, I think you missed changing the entity here: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/mail/extensions/offline/content/msgOfflineOverlay.xul&rev=1.9&mark=68#53

good catch Adam!

The entity names were not changed in the branch checkin.

This could use a post to .l10n to explain if localizers are supposed to catch up on this and what's required. From a coding point of view, having entities called flagFoo that say "Star foo" smells pretty hacky, and from an l10n point of view, is happy to break.

(In reply to comment #7) > This could use a post to .l10n to explain if localizers are supposed to catch > up on this and what's required. That's a great idea. I will do that. > > From a coding point of view, having entities called flagFoo that say "Star foo" > smells pretty hacky, and from an l10n point of view, is happy to break. I'm not sure what you mean here. I changed the entity names when I made this semantic name change from Flag to Star. The entity names all have 'Star' in the names.

It looks like I attached an old patch in this bug instead of the one where I actually changed the entity names! And then to make matters worse, I landed the old patch on the 1.8.1 branch instead of what I checked into the trunk. thanks for catching this Axel. I'll back out what I landed on the 1.8.1 branch and will then re-land what went into the trunk. I'll follow that up with some time in the penalty box.

Comment on attachment 230971 [details] [diff] [review] [fixed branch and trunk] this is the patch I really meant to check in (and it landed on the trunk) Ok I've landed the correct patch on the branch this time.

In messenger.properties there are still "flagged" properties saying "starred": +#Grouped by starred +notFlagged=Not Starred +groupFlagged=Starred -flagged=Flagged +flagged=Starred

One meta-issue of using "star" instead of "flag" is that searching for the string 'star' brings up 'startup' and 'restart' whereas flag has no such issue. Also, "flag" is a legitimate verb. "Flagging" a message is sensible, but "starring" it just sounds wrong. Damn Google's eyes! (An advantage to "star" is that it won't be confused with the junk or new flags -- these latter instances of "flag" being more internal terms but still a source of confusion.) Are you going to provide a toolbar button for Star? Or just leave it a subset of Mark?

Any idea on whether changing this text is called for? http://lxr.mozilla.org/mailnews/source/mailnews/base/src/nsMsgDBView.cpp#176 (the string for kFlaggedMsgAtom) I'm looking at bug 342009 and trying to get customization for flagged messages working (with no success yet). Once I get it working, the recommendation will include the selector treechildren::-moz-tree-cell-text(flagged) which ought to work now, but won't be obvious if it remains "flagged" and may break existing customizations if it becomes "starred".

not keen on the automatic starred folder idea just to be gmail-like. Shouldn't it be in views anyway?

(In reply to comment #15) > not keen on the automatic starred folder idea just to be gmail-like. Shouldn't > it be in views anyway? I second that. I personally don't use Gmail, but the main reason for being against the idea is that, out of principle, I don't like automagically appearing stuff. At least a preference should be (IMHO) available to turn this off...

I would appreciate it very much if there was an easy way to display only the starred mails in my main message view. Best would be to make both approaches possible and let the user decide whether he wants to access his starred mail via a folder or View/Messages menu.

There is: just create a custom view. Created a new bug (bug 425359) for considering the automatic virtual folder creation. The renaming is FIXED.