941454 - Update text in clear private data prompt

Status: VERIFIED FIXED

(Firefox for Metro Graveyard :: Flyouts, defect, P2)

Description

[Rodrigo Silveira [:rsilveira] [:rodms]]

From Yuan's comment 4 in bug 940211
1. Make the header lower case. Use "Clear private data".
2. Update the stings under the header. Use: This will permanently delete the private data you have selected in “Options”.

Comment 1

[Allison Naaktgeboren :ally]

Attachment: clearPrivateDataStrChange

The properties names change so the localization dashboard will detect the string change. 

I didn't use PuralForm.get() because it requires an exact count as a value and "Options" does not have one. For those languages where the verbs might shift with the value of optionsCharm or in which languages optionsCharm does have a specific numerical value, there is a localization note so they can adjust the message as needed.

Comment 2

[Matt Brubeck (:mbrubeck)]

Comment on attachment 8368086 [details] [diff] [review]
clearPrivateDataStrChange

“Options” should be enclosed in quotation marks, and the sentence should end with a period.

I think it would be simpler (both in code and for localizers) to make this a single string without the substitution (i.e., just end with "...data you have selected in “Options.”").  I doubt we will change the name "Options", but if we ever do we can just update both strings.

Comment 3

[Allison Naaktgeboren :ally]

Attachment: clearPrivateDataStrChange

I'm happy enough to ship a smaller simpler patch.

Comment 4

[Allison Naaktgeboren :ally]

remote:   https://hg.mozilla.org/integration/fx-team/rev/5744bf41d817

Comment 5

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/5744bf41d817

Comment 6

[Francesco Lodolo [:flod]]

(In reply to Matt Brubeck (:mbrubeck) from comment #2)
> “Options” should be enclosed in quotation marks, and the sentence should end
> with a period.

Just checking if I'm reading the code right: in the end this didn't happen, correct?

Comment 7

[Matt Brubeck (:mbrubeck)]

Whoops, it looks like the first version of the patch landed by accident, rather than the second version that was reviewed.  Ally, could you land a fix for this?  (We'll need to increment the numbers in the property names again.)

Comment 8

[Marco Mucci [:MarcoM]]

Hey Ally, can you provide a point value.

Comment 9

[Allison Naaktgeboren :ally]

ack! this is what I get for landing code while sick as a dog. Yes, Ill fix it. Marco p=2

Comment 10

[Allison Naaktgeboren :ally]

Attachment: clearPrivateDataStrChange fixing my incorrect landing

Fixing my incorrect landing. Please land.

Comment 11

[Matt Brubeck (:mbrubeck)]

Comment on attachment 8370228 [details] [diff] [review]
clearPrivateDataStrChange fixing my incorrect landing

Review of attachment 8370228 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks; r=mbrubeck after dropping two unneeded changes (below).

::: browser/metro/base/content/browser-ui.js
@@ +1141,5 @@
>    },
>  
>    confirmSanitizeDialog: function () {
>      let bundle = Services.strings.createBundle("chrome://browser/locale/browser.properties");
> +    let title = bundle.GetStringFromName("clearPrivateData.title3");

See below.

::: browser/metro/locales/en-US/chrome/browser.properties
@@ +37,5 @@
>  contextAppbar2.clear=Clear selection
>  
>  # Clear private data
>  clearPrivateData.clearButton=Clear
> +clearPrivateData.title3=Clear private data

Oh, I guess you can leave this change out -- the string hasn't changed so the property name doesn't need to change either.

Comment 12

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/integration/fx-team/rev/24757ffc7073

Comment 13

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/24757ffc7073

Comment 14

[Kamil Jozwiak [:kjozwiak]]

Went through the following verification using the following Nightly build:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-02-11-03-02-01-mozilla-central/

- Ensured that the text strings are matching the strings mentioned in comment #0
- Ensured that only the "Clear" string is capitalized as per comment #0
- Ensured that the string "Options" is enclosed in quotes as per comment #2
- Ensured that the modal window still works without any issues (Clearing/Cancelling)
- Ensured that resizing the window into several snapped configurations correctly aligned the modal window including the strings
- Ensured that you cannot interact with the web page in the background once the modal window is visible

We are still overlapping the modal window with the "Options" flyout, that particular ticket can be found at Bug #953072. Also found another issue that is relating to the "Clear private data" modal, created ticket Bug #971081