241249 - Text in column picker "restore natural order" is unclear to user

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Patrick]

[Jan, this is a follow up on bug 222096 and spun off as a separate issue from
bug 221619 comment 29. This way the issue gets evaluated from any of the other
issues in that meta bug.]

Issue: i think it's unclear to the user what "natural" order is. I'm not aware
of  any other software using that terminology, but apart from that, i think
"restore default order" is a much more common way of putting it.

Comment 1

[Jan Varga [:janv]]

As I said, I let others to decide.

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

can we insert a "column" somewhere in that text. when seeing this I had _no_
idea what thing this was ordering.

Comment 3

[timeless]

Attachment: I have no clue what the current text means

Comment 4

[Jan Varga [:janv]]

You forgot to fix mozilla/toolkit too.

Comment 5

[timeless]

mozilla/xpfe/global/resources/locale/en-US/tree.dtd 	1.2

Comment 6

[Wayne Mery (:wsmwk)]

TB Column picker still shows "restore natural order", not "Reset Column Ordering".
fixed for suite, but not for Thunderbird. 
Is a new bug needed for Thunderbird?

TB trunk version 1.6a1 (20051109)

Comment 7

[Patrick]

(In reply to comment #6)
> TB Column picker still shows "restore natural order", not "Reset Column
> Ordering".

and per comment 4 --> reopening.

Attaching patch shortly that changes
  mozilla/toolkit/locales/en-US/chrome/global/tree.dtd
to "Reset Column Ordering"

Comment 8

[Patrick]

Attachment: Patch for mozilla/toolkit

Comment 9

[Patrick]

Sorry Timeless, didn't mean to steal your bug [i don't ask for review often]
Also, do i have to change something when it comes to whom i'm asking review from?

Comment 10

[Mike Connor [:mconnor]]

Comment on attachment 202812 [details] [diff] [review]
Patch for mozilla/toolkit

r=me with "Restore Defaults" per discussion with beltzner

Comment 11

[Patrick]

Comment on attachment 202812 [details] [diff] [review]
Patch for mozilla/toolkit

Who should be sr for this?

Comment 12

[[e-mail]]

Comment on attachment 202812 [details] [diff] [review]
Patch for mozilla/toolkit

mconnor's review suffices, but I guess you'll need to beg someone to check it in.

Comment 13

[Patrick]

(In reply to comment #12)
> (From update of attachment 202812 [details] [diff] [review] [edit])
> mconnor's review suffices, but I guess you'll need to beg someone to check it
> in.
> 

Neil, pretty please? Will you check this in for me?
;)

Comment 14

[[e-mail]]

Sorry, I don't do other people's toolkit-only checkins.

Comment 15

[Patrick]

Jan, can you please check this in for me?

Comment 16

[Jan Varga [:janv]]

ok

Comment 17

[Jan Varga [:janv]]

Comment on attachment 202812 [details] [diff] [review]
Patch for mozilla/toolkit

checked in

Comment 18

[Patrick]

Looking at
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=tree.dtd&branch=&root=/cvsroot&subdir=mozilla/toolkit/locales/en-US/chrome/global&command=DIFF_FRAMESET&rev1=1.1&rev2=1.2
it seems that something else than attachment 202812 [details] [diff] [review] was checked in?

Comment 19

[Jan Varga [:janv]]

See comment 10

Comment 20

[Patrick]

(In reply to comment #19)
> See comment 10

should 
mozilla/xpfe/global/resources/locale/en-US/tree.dtd 
be changed accordingly then?

Comment 21

[Wayne Mery (:wsmwk)]

(In reply to comment #10)
> (From update of attachment 202812 [details] [diff] [review] [edit])
> r=me with "Restore Defaults" per discussion with beltzner

unless "restore defaults" restores both column choices and column order I can't agree this is a good choice of wording nor an improvement - "restore defaults" is just as vague as "restore natural order", perhaps even less accurate.

Comment 22

[[e-mail]]

(In reply to comment #20)
>should mozilla/xpfe/global/resources/locale/en-US/tree.dtd be changed accordingly then?
No, that was fixed satisfactorily by attachment 147057 [details] [diff] [review], so to change it you'd have to persuade at least timeless and myself; I won't accept "Restore Defaults" although I'd consider a compromise such as "Restore Default Ordering", otherwise I guess that this bug is well and truly fixed.

Comment 23

[John Gaunt (redfive)]

I wanted to point out that the toolkit version of this string has not been changed on the branch, so XULRunner users on the branch are still getting "Restore Natural Order". Yet the xpfe version appears to be checked in at both places.

Was that an oversight or by design? If by design can someone comment about the reasoning?

Comment 24

[[e-mail]]

(In reply to comment #23)
>I wanted to point out that the toolkit version of this string has not been
>changed on the branch, so XULRunner users on the branch are still getting
>"Restore Natural Order". Yet the xpfe version appears to be checked in at both
>places.
tree.dtd only exists on the trunk...

Comment 25

[John Gaunt (redfive)]

(In reply to comment #24)
> (In reply to comment #23)
> >I wanted to point out that the toolkit version of this string has not been
> >changed on the branch, so XULRunner users on the branch are still getting
> >"Restore Natural Order". Yet the xpfe version appears to be checked in at both
> >places.
> tree.dtd only exists on the trunk...
> 

Not according to lxr or my xulrunner build:
http://lxr.mozilla.org/mozilla1.8/find?string=tree.dtd

Comment 26

[[e-mail]]

I'm sorry, I misread the CVS history.
The xpfe version got changed before the 1.8 branch, so it picked it up.
The toolkit version didn't get changed until after the 1.8 branch.
I don't know why nobody requested branch approval for the toolkit version.