315633 - "Create Profile" dialog text doesn't match button text: "Click Finish"->"Done", "click Next"->"Continue"

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[Steuard Jensen]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051025 Firefox/1.5
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051025 Firefox/1.5

The text shown when creating a new profile for Firefox does not match the actual button names.  

Reproducible: Always

Steps to Reproduce:
1. Run firefox -P to open profile manager.
2. Select "Create profile..." and proceed through creation process.

Actual Results:  
The last line of the "Introduction" page says "To begin creating your profile, click Next", but the button reads "Continue".

The last line of the "Conclusion" page says "Click Finish to create this new profile", but the button reads "Done".


Expected Results:  
The text in the dialog box should match the actual button text.  This makes Firefox look sloppy and unprofessional, and I'd like to think it would be an easy fix.

I'm guessing that this is a mismatch between the button names on Windows and Mac, but I haven't checked that.

Comment 1

[Steuard Jensen]

Attachment: Use Mac-appropriate text in profile creation

This patch adds Mac-appropriate text to the createProfileWizard DTD and profileSelection.properties file (in the en-US locale).  The appropriate text is selected in the createProfileWizard.{xul,js} using platform #ifdefs.  The patch is against the 1.8 branch, but I expect that it will be necessary (and similar) on the trunk, too.

If adding platform-specific strings to the DTD isn't the preferred approach for this sort of thing, let me know what the right way is.  To be safe, someone should probably test this patch on other platforms to make sure it doesn't cause any problems (though it's simple enough that I don't expect much trouble).

This is my first real attempt to submit a patch from scratch, so let me know if I've suggested the wrong reviewer or if there's anything else that I need to do here.  (In particular, should I request superreview now, or wait until I've got a positive review first?)  Also, I should mention in advance that I don't have a CVS account (nor do I want that level of responsibility), so I'm going to be depending on the kindness of strangers to get this code checked in.

Comment 2

[Steuard Jensen]

Adding component peers to CC list, and requesting blocking for various upcoming releases (I'm not sure which would be most appropriate).

Comment 3

[Benjamin Smedberg]

Minor polish bugs don't count as blockers, and we hide the profile management UI as much as possible anyway.

Comment 4

[Daniel Veditz [:dveditz]]

Comment on attachment 206616 [details] [diff] [review]
Use Mac-appropriate text in profile creation

blame says bsmedberg so delegating sr= request to him, change r= to josh for mac platform consistency checking.

Comment 5

[Josh Aas]

Comment on attachment 206616 [details] [diff] [review]
Use Mac-appropriate text in profile creation

> profileFinishMacText

For consistency, please make "Mac" a suffix, don't put it before "Text"

Fix that and r+. Just do it on checkin.

Comment 6

[Benjamin Smedberg]

Comment on attachment 206616 [details] [diff] [review]
Use Mac-appropriate text in profile creation

I wish it was easy to re-use the existing entities in wizard.properties, but it doesn't appear so.

Comment 7

[Steuard Jensen]

(In reply to comment #6)
> (From update of attachment 206616 [details] [diff] [review] [edit])
> I wish it was easy to re-use the existing entities in wizard.properties, but it
> doesn't appear so.

Now that you mention it, maybe it is possible: is there anything wrong with including text preprocessor #ifdef's in the DTD and .properties files?  That would require changes to the locale jar.mn rather than to the profile jar.mn, but then the profile manager XUL and JS files wouldn't need to be altered at all.

(I'll try putting together a new patch using that approach if I can, but for some reason my mozilla source tree has decided to stop compiling at the moment.)

Comment 8

[Benjamin Smedberg]

You may not use preprocessor defines in localizable files because then langpacks would not be platform-agnostic.

Comment 9

[Steuard Jensen]

Attachment: Update of reviewed patch as per comment 5

I'm posting an update to my previous patch incorporating the parameter name change requested in comment 5.  As I don't have checkin privlidges, this should make life easier for whoever ends up landing the fix.  Speaking of which, if anyone would like to volunteer to check this in, I'd appreciate it.  Thanks.

(Should I have set this patch to obsolete the previous patch?  Would doing so have lost the approval bits in the system?  Sorry for the newbie questions...)

Comment 10

[Josh Aas]

checked in on trunk, leaving this open until I can check in on branch later today

Comment 11

[Josh Aas]

landed on MOZILLA_1_8_BRANCH