342350 - late string changes for add-on compatability update wizard

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

Some string changes for clarity ..:

<!ENTITY  mismatch.intro-1.label          "The following add-ons are not compatible with this version of &brandShortName;">

 - not necessarily a newer version
 - user didn't necessarily install it (could be auto-updated)

<!ENTITY  mismatch.intro-3.label          "&brandShortName; can check for compatible versions of these add-ons.">

 - that's all we start with, right? just a check? then we ask them to confirm the installation

+<!ENTITY  updateFound.addons.label        "Updates are available for the following add-ons to them compatible with this version of &brandShortName;">

 - better explanation of what these updates represent

+<!ENTITY  found.xpinstallDisabled.label   "These updates can't be installed because software installation is currently disabled. You can change this setting below.">

 - I know, I should have made it right the first time ;)

+<!ENTITY  finished.remain.label           "No compatible versions of the following add-ons could be found. These add-ons will be disabled, but &brandShortName; will check periodically and inform you when compatible versions become available.">

 - this is assuming we still show the list of add-ons that will be disabled.

When bug 310745 lands I can whip together a patch, or if Robert would rather make these changes before 310745 lands on the branch, I can just put together a patch for trunk tonight. His choice since it was my bad to have these in so late.

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #0)
> +<!ENTITY  updateFound.addons.label        "Updates are available for the
> following add-ons to them compatible with this version of &brandShortName;">
> 
>  - better explanation of what these updates represent

Or, you know, horribly broken one. I don't know what happened to the version I thought I was submitting. Let's try that again!

<!ENTITY  updateFound.addons.label        "Updates are available for the
following add-ons to make them compatible with this version of &brandShortName;">

Comment 2

[Robert Strong (they/them - no direct email)]

Are you sure you want to remove the colons at the end of the strings. These strings are immediately before the displayed list.

Comment 3

[Robert Strong (they/them - no direct email)]

If not, do you want a period at the end of the strings instead?

Comment 4

[Robert Strong (they/them - no direct email)]

Attachment: patch using colons

beltzner, I'm submitting with and without colons for you to choose from.

Comment 5

[Robert Strong (they/them - no direct email)]

Attachment: patch without colons

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 226540 [details] [diff] [review]
patch using colons

Colons, please. Should there not be one at the end  in finished.remain1.label, as well?

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 226541 [details] [diff] [review]
patch without colons

Not this one, which was my own doing and poopy. :(

Comment 8

[Robert Strong (they/them - no direct email)]

Hey beltzner, I decided to dive in and take a look at some of this and it is as I feared... there is some really old cruft that is preventing that string as well as others from being used. I'm going to create a patch that fixes that but I really would like a pony for doing so.

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

I will buy you a pony.

Comment 10

[Robert Strong (they/them - no direct email)]

beltzner, that string is no longer needed and I am going to file a followup bug to remove it and go with the current patch as is to avoid impacting l10n anymore than this is already.

Comment 11

[(not reading, please use [e-mail] instead)]

Comment on attachment 226540 [details] [diff] [review]
patch using colons

r=sspitzer

Comment 12

[Robert Strong (they/them - no direct email)]

Checked in to trunk and filed Bug 342606 for the unreachable code path cleanup.

Comment 13

[Robert Strong (they/them - no direct email)]

Comment on attachment 226540 [details] [diff] [review]
patch using colons

I held off on landing bug 310745 which already has a1.8.1 so some of these strings wouldn't be changed twice for l10n.

Comment 14

[Darin Fisher]

Comment on attachment 226540 [details] [diff] [review]
patch using colons

a=darin on behalf of drivers

Comment 15

[Robert Strong (they/them - no direct email)]

Checked in to MOZILLA_1_8_BRANCH for Firefox 2.0