finish string changes for "folder properties" dialog

RESOLVED FIXED

Status

RESOLVED FIXED
18 years ago
10 years ago

People

(Reporter: sspitzer, Unassigned)

Tracking

Trunk
x86
Other

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

spun off of bug #78891

finish string changes for "folder properties" dialog

specifically:  

1) if you want to set the title dynamically, use a string bundle to store the
format string.

2) there were a bunch of string changes from #78891 that never landed.  this bug
is the place to attach a patch for all those changes.

there isn't a spec for this dialog, so please attach screen shots so that jglick
can review (and possible add the screen shots to the spec)

Comment 1

18 years ago
cc to l10n

Updated

18 years ago
QA Contact: esther → sheelar
http://www.nexgenmedia.net/mailfolderpref1.png
http://www.nexgenmedia.net/mailfolderpref2.png

List of proposed changes:

1. Folder name to go into title ("foldername" Properties)
2. "General Information" -> "General"
3. The "General" tab chechbox to be inverted in functionality - you need to
check it if you want to force the default to all new message
Status: NEW → ASSIGNED

Comment 3

18 years ago
I think you should make the OK and Cancel buttons right-aligned there.
Håkan, a separate bug about the Windows version of dialogOverlay.xul should be
filed for moving the buttons.

Comment 5

18 years ago
Created attachment 36801 [details]
proposed

Comment 6

18 years ago
"Offline Use" should be "Offline"

Title should probably be "Folder Properties" not "<NameOfFolder> Properties". 
Otherwise, its not as clear what the "Name" text field on the General tab is 
for.

Comment 7

18 years ago
Also, after seeing the character coding settings on the General tab in the 
current builds, are we sure we want to do this?  Most users have no clue what 
character coding is and will never change it. Do we want it on the General tab, 
in user's faces whenever they open this dialog?  Having it on its own tab had 
the benefit of making it accessible for those users who are interested, but out 
of the way for users who don't need or understand it.

Comment 8

18 years ago
Created attachment 36805 [details]
for example

Comment 9

18 years ago
he wording change from
"Apply default to all messages (ignore charset specified by MIME header)"
to
"Allow messages to specify other encodings".

I think this is corresponding to the recent font preference change from
"Always use my font settings, overriding web page font"
to
"Allow documents to use other fonts".

jglick, please talk to german for his comment about the font pref wording change.

A couple of comments,
* There is a global override setting in message display preference. That has to
by synchronized if the wording of the folder property will change.
* "Allow messages to specify other encodings", "encoding" is not used in other
places in the product, "Character Coding" is used.

Comment 10

18 years ago
"T" was missing,
he wording change from - > The wording change from

Comment 11

18 years ago
nhotta, as an international rep, please specify what you suggest the wording for 
this item should be.  I'll be the first to admit i don't know enough about 
character coding to suggest the correct wording for this item.

Comment 12

18 years ago
I think the current wording is fine, I did not propose for the change.
But if the change is necessary then I would suggest "Character Coding" instead
of "encoding".

Comment 13

18 years ago
I agree with Nhotta that the wording changes are good.

In response to Jglick:

You can't change the title to "Folder Properties" instead of "<NameOfFolder>
Properties" because you can do properties on Local Folders, on News Accounts,
Newsgroups, POP3 Accounts and usual folders. Hence why you cannot hardcode
"Folder" in there.

I don't think Character Encoding should be its own tab. That may just make the
user confused because there are so few options on that tab. However, a tooltip
for the popupmenu describing when and why to use it would probably be good.

Comment 14

18 years ago
>You can't change the title to "Folder Properties" instead of "<NameOfFolder>
>Properties" because you can do properties on Local Folders, on News Accounts,
>Newsgroups, POP3 Accounts and usual folders. Hence why you cannot hardcode
>"Folder" in there.

I AGREE using "Folder Properties", "Account Properties", "Newsgroup Properties" 
etc., where appropriate is correct.  What I am NOT suggesting is using "Sent 
Properties" instead of "Folder Properties" as the name of the dialog when the 
Sent folder is selected.

>I don't think Character Encoding should be its own tab. That may just make the
>user confused because there are so few options on that tab.

I don't believe having too few options makes users confused. Having options 
which most users don't understand and will never use in a prominent location is 
what will potentially confuse them.
i think the general tab is somewhat useless and empty

Comment 16

18 years ago
>I AGREE using "Folder Properties", "Account Properties", "Newsgroup Properties" 
etc., where appropriate is correct.  What I am NOT suggesting is using "Sent 
Properties" instead of "Folder Properties" as the name of the dialog when the 
Sent folder is selected.

Yes that makes sense, I completely agree with you. (Be nice with the caps ;)  )

Regarding the General tab... Hmm... It's tricky. I would prefer to not have it
there as its own tab with one sole widget in it. In all honesty, do we actually
need a Character Encoding popupmenu in this dialog at all? If not, removing it
would help alot. I don't know.

Comment 17

18 years ago
>I agree with Nhotta that the wording changes are good.
I meant that the existing one is fine so no need to change it unless it wants to
be consistent with a font preference wording. That is a cross component issue
and that's why I cc german.

Comment 18

18 years ago
Yes, the General tab has only one item in in now, but I believe there are plans 
to add additional summary data, such as total number of read/unread messages in 
the folder.  What happens when this gets added?  We move Char Coding back to its 
own tab?  An example of 4.x tab will be attached below.

(sorry about the caps, wasn't shouting, just trying to stress the different 
points) 

Comment 19

18 years ago
Created attachment 36840 [details]
4.x General tab
nhotta: I used `encoding' rather than `coding' because while both are
understandable English words, `encoding' is more precise and is what the IETF
and the W3C use (not to mention being what Microsoft uses in Internet Explorer
for Windows). I know `coding' is used in (two?) other places in Mozilla's UI,
but there is plenty of time to fix those as well.

jglick: Please refer to the Info window on Mac OS, and the Properties window on
Windows, for a selected folder. Their titles are `foobar Info' and `foobar
Properties' respectively, even though the folder name is also included in the
content of the window. Having the item name in the title is especially useful
when you have more than one properties window open.

With regard to the separate tab, I think that {badness caused by a nearly-empty
tab} + {badness caused by a mysterious third tab} > {badness caused by two
encoding controls in the `General' tab}. The properties window is abnormally
short currently, so there is plenty of room to add other elements (such as
message counts) to the `General' tab. (By the way, please remember that tabs
shouldn't have accesskeys. The accesskey for `Allow messages to specify other
encodings' should be `o', like it is for `Allow documents to use other fonts'.)

Håkan: In general, only toolbar buttons should have tooltips. Other (already
labelled!) items are supposed to be understandable enough without tooltips,
otherwise you've got bigger troubles to worry about than adding tooltips everywhere.

Comment 21

18 years ago
> nhotta: I used `encoding' rather than `coding' because 
> while both areunderstandable English words, `encoding' 
> is more precise and is what the IETF and the W3C use 
> (not to mention being what Microsoft uses in Internet 
> Explorer for Windows). 

We considered "Character Encoding", "Character Code" beside
"Character Coding" in the original discussion we had in
the mozilla-i18n/ui newsgroups. What we have under 
the menu items were not all "encoding" items. Auto-detection
modules are not "encodings" but just methods to detect
certain encodings. Rather than calling these disparate
items "encoding", we took a more neutral term which does
not have a specific affliation with the encoding names.

Thus "encoding" is not necessarily an approprite term
in our menu context. Neither it is in the current 
IE which mixes encoding and auto-detection modules under a single menu. IETF and
W3C documents use the term in a 
precise way and I don't believe adopting "Character 
Encoding" for this menu will be an improvement. 
I oppose changing of the name for the menu for these 
reasons. 


Comment 22

17 years ago
This dialog has already changed. An updated spec is available at
http://www.mozilla.org/mailnews/specs/folder/ which I'm looking at implementing.
This bug could be part of the necessary changes.

Updated

17 years ago
QA Contact: sheelar → huang
Product: Browser → Seamonkey
Assignee: doronr → mail
Status: ASSIGNED → NEW
QA Contact: huang
This bug is being marked EXPIRED as it has seen no activity in a very long time.

If you think that the issue reported might still be relevant, please test with a recent release of SeaMonkey and if the problem persists feel free to re-open the report. Thank you.

http://www.seamonkey-project.org/
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → EXPIRED
Bulk reopening incorrectly expired bugs - no activity does not constitute no bug - these need proper checking.
Status: RESOLVED → REOPENED
Resolution: EXPIRED → ---

Comment 25

10 years ago
Looks finished to me. For any additional string changes, please file a new bug.
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.