To simplify the download button UI, we want the ability to move all “other” links (except for “Privacy”) elsewhere on the page. * Desired use cases: - Download button with all “other” links displayed (current default) - Download button with only “Privacy” link beneath (required by legal) and “other” links displayed elsewhere on the page * Current “other” links [1]: Android - Supported Devices - Systems & Languages - What’s New - Privacy iOS - Supported Devices - Privacy Desktop (Linux/OS X/Windows) - Systems & Languages - What’s New - Privacy In addition to the above, the following string changes have been requested: - “Systems & Languages” -> “Download Firefox for Other Platforms and Languages (English)” - “What’s New” -> “Release Notes (English)” - "Privacy" -> "Firefox Browser Privacy Notice" [1] https://github.com/mozilla/bedrock/blob/master/bedrock/firefox/templates/firefox/includes/download-button.html#L82-L112

Additional thoughts: * "other" links vary based on platform Since "Privacy" needs to stay next to the button, iOS users will only have 1 link available to relocate ("Supported Devices"). This may prove tricky, as there are no nearby related links to give context if relocating away from the download button. (This is more of a UX issue, but worth mentioning here.) * Add parameter to download_firefox helper It would be nice to add a parameter to the download_firefox helper to indicate if all "other" links should be included in the returned markup, and would have a default value of True. This would essentially provide an "opt-in" policy for relocating the "other" links (so as to not break existing implementations).

(In reply to Jon Petto [:jpetto] from comment #0) > To simplify the download button UI, we want the ability to move all “other” > links (except for “Privacy”) elsewhere on the page. > - “Systems & Languages” -> “Download Firefox for Other Platforms and > Languages (English)” > - “What’s New” -> “Release Notes (English)” I have been meaning to ask this question. We have English in parenthesis after the links, is this always English or, does/should this reflect the current locale?

Spoke to agibson on IRC and I now understand the (English) is there to indicate that those pages are available in English only. Clearing need info

(In reply to Jon Petto [:jpetto] from comment #0) > > - “Systems & Languages” -> “Download Firefox for Other Platforms and > Languages (English)” > - “What’s New” -> “Release Notes (English)” > - "Privacy" -> "Firefox Browser Privacy Notice" > Just wanted to confirm, in https://bugzilla.mozilla.org/show_bug.cgi?id=1213372#c15 it is stated that the privacy link text should be "Firefox Privacy Notice" has this changed to "Firefox Browser Privacy Notice"

In the first comment [1], it's requested to be "Firefox Browser Privacy Notice" (which is approved by :matej in comment 3 [2]), and :agibson's /new work [3] matches, so I *think* that's the correct string. My guess is that comment 15 is talking more about placement and not the exact string. (This whole requirements process has been a little messy. :/) [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1213372#c0 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1213372#c3 [3] https://bedrock-demo-agibson.us-west.moz.works/en-US/firefox/new/?v=1a

(In reply to Jon Petto [:jpetto] from comment #0) > - “Systems & Languages” -> “Download Firefox for Other Platforms and > Languages (English)” > - “What’s New” -> “Release Notes (English)” > - "Privacy" -> "Firefox Browser Privacy Notice" In which context would these strings be used? If you account for +30%, "Download Firefox for Other Platforms and Languages (English)" could easily become a 80-90 characters strings.

(In reply to Francesco Lodolo [:flod] from comment #6) > (In reply to Jon Petto [:jpetto] from comment #0) > > - “Systems & Languages” -> “Download Firefox for Other Platforms and > > Languages (English)” > > - “What’s New” -> “Release Notes (English)” > > - "Privacy" -> "Firefox Browser Privacy Notice" > > In which context would these strings be used? If you account for +30%, > "Download Firefox for Other Platforms and Languages (English)" could easily > become a 80-90 characters strings. Strings have been discussed in various bugs and in a meeting yesterday. This is what I understand the strings to be moving forward. These are a little shorter as length was a concern for us also. (need-info jbertsch to confirm for flod) - "Firefox for Other Platforms & Languages" (still long, but an improvement) - "Firefox Privacy" (approved by legal this week) - "Release Notes" See also, https://bugzilla.mozilla.org/show_bug.cgi?id=1213372#c22

Also please see https://bugzilla.mozilla.org/show_bug.cgi?id=1213372#c24

Logic for the footer links are as follows: The links I am referring to are: Firefox for Other Platforms & Languages Release Notes Supported Devices ------- First, these will appear only on products pages. Secondly, for the following pages, it will show the links for the product platform, not the viewing platform: /firefox/desktop /firefox/all firefox/[ver]/releasenotes/ /firefox/android firefox/android/all/ firefox/android/[ver]/releasenotes/ /firefox/ios firefox/ios/]ver]/releasenotes/ firefox/developer/ firefox/developer/all/ firefox/[ver]/auroranotes/ i.e. If viewing /firefox/desktop on an Android device, the links in the footer will still be for desktop Firefox. Viewing /firefox/android will show the Firefox for Android links even when viewed on a desktop browser. For: /firefox/new/?scene=1 /firefox/new/?scene=2 The links in the footer will match the viewing platform so, viewing the page on Android, will show links for Android, viewing on desktop will show desktop etc. These links will not be shown on any other pages.

Ignore comment 8 and refer to https://bugzilla.mozilla.org/show_bug.cgi?id=1259211#c9

Writing here too (less chance to lose it) https://github.com/mozilla/bedrock/pull/4070 There is one change that could have l10n downsides: "Download now" -> "Download". "Download" is a tricky word in English (like "bookmark"), since it could either be a verb or a noun. And technically we have no way to differentiate them. "Download now" is clearly a verb, so no chance of confusion there. How do you feel about using "Download" for en-*, and keep the existing translation of "Download now" for localized versions? If that doesn't work, we need to find a way to differentiate them, e.g. Download -> noun <em>Download</em>, Download&nbsp;, etc. -> verb (and in case use CSS to don't change the aspect, not sure if there's a more neutral tag to use in these cases)

I'd also like to confirm that the whole "(English)" thing was dropped, since I don't see it in the PR.

(In reply to Francesco Lodolo [:flod] from comment #13) > I'd also like to confirm that the whole "(English)" thing was dropped, since > I don't see it in the PR. Yes, the (English)part has been dropped, partly to assist in shortening the length of the strings, and because we do not do that consistently across the site for items that are available in English only.

(In reply to Francesco Lodolo [:flod] from comment #12) > Writing here too (less chance to lose it) > https://github.com/mozilla/bedrock/pull/4070 > > There is one change that could have l10n downsides: "Download now" -> > "Download". > > "Download" is a tricky word in English (like "bookmark"), since it could > either be a verb or a noun. And technically we have no way to differentiate > them. "Download now" is clearly a verb, so no chance of confusion there. > > How do you feel about using "Download" for en-*, and keep the existing > translation of "Download now" for localized versions? If that doesn't work, > we need to find a way to differentiate them, e.g. > Download -> noun > <em>Download</em>, Download&nbsp;, etc. -> verb (and in case use CSS to > don't change the aspect, not sure if there's a more neutral tag to use in > these cases) Let's go with Flod's recommendation. Schalk, if you see any spacing/width issues in the sticky nav, could you flag asap? Going to need-info Troy on this one so that he is aware this locale challenge and can sign off. Troy, see comment 12

At the top of the /all pages there are two links 1) Check the system requirements 2) Release notes Do we want to remove these in favor of the links that are now in the footer or, should these be left as is?

Also, recently we added the "Systems & Languages" copy to the send to device widget. Should we keep this, remove, or just update the copy to match the copy in the footer?

(In reply to Schalk Neethling [:espressive] from comment #16) > Created attachment 8742757 [details] > Screen Shot 2016-04-19 at 13.28.33.png > > At the top of the /all pages there are two links > > 1) Check the system requirements > 2) Release notes > > Do we want to remove these in favor of the links that are now in the footer > or, should these be left as is? Keep these links for now. My guess is that they are prioritized because they may be more important than footer content for the users who come to /all. Do we have GA data for these links? That could help us decide. (need-info Jbertsch)

(In reply to Schalk Neethling [:espressive] from comment #17) > Created attachment 8742759 [details] > Screen Shot 2016-04-19 at 13.33.48.png > > Also, recently we added the "Systems & Languages" copy to the send to device > widget. Should we keep this, remove, or just update the copy to match the > copy in the footer? If the equivalent link is now in the footer, I would vote to remove it in the Send to Device widget. My reasons are to simplify the send to device widget and allow there to be less links to focus on in this area. Send and Playstore buttons are the main objective here for the user. However, Jen should also sign off on removing the Systems & Languages link from this.

(In reply to Holly Habstritt Gaal [:Habber] from comment #15) > (In reply to Francesco Lodolo [:flod] from comment #12) > > Writing here too (less chance to lose it) > > https://github.com/mozilla/bedrock/pull/4070 > > > > There is one change that could have l10n downsides: "Download now" -> > > "Download". > > > > "Download" is a tricky word in English (like "bookmark"), since it could > > either be a verb or a noun. And technically we have no way to differentiate > > them. "Download now" is clearly a verb, so no chance of confusion there. > > > > How do you feel about using "Download" for en-*, and keep the existing > > translation of "Download now" for localized versions? If that doesn't work, > > we need to find a way to differentiate them, e.g. > > Download -> noun > > <em>Download</em>, Download&nbsp;, etc. -> verb (and in case use CSS to > > don't change the aspect, not sure if there's a more neutral tag to use in > > these cases) > > Let's go with Flod's recommendation. Schalk, if you see any spacing/width > issues in the sticky nav, could you flag asap? > > Going to need-info Troy on this one so that he is aware this locale > challenge and can sign off. > > Troy, see comment 12 Sounds good to me. Thanks, Holly.

(In reply to Holly Habstritt Gaal [:Habber] from comment #19) > (In reply to Schalk Neethling [:espressive] from comment #17) > > Created attachment 8742759 [details] > > Screen Shot 2016-04-19 at 13.33.48.png > > > > Also, recently we added the "Systems & Languages" copy to the send to device > > widget. Should we keep this, remove, or just update the copy to match the > > copy in the footer? > > If the equivalent link is now in the footer, I would vote to remove it in > the Send to Device widget. My reasons are to simplify the send to device > widget and allow there to be less links to focus on in this area. Send and > Playstore buttons are the main objective here for the user. However, Jen > should also sign off on removing the Systems & Languages link from this. Let's remove it from the widget. Thanks.

(In reply to Holly Habstritt Gaal [:Habber] from comment #18) > (In reply to Schalk Neethling [:espressive] from comment #16) > > Created attachment 8742757 [details] > > Screen Shot 2016-04-19 at 13.28.33.png > > > > At the top of the /all pages there are two links > > > > 1) Check the system requirements > > 2) Release notes > > > > Do we want to remove these in favor of the links that are now in the footer > > or, should these be left as is? > > Keep these links for now. My guess is that they are prioritized because they > may be more important than footer content for the users who come to /all. Do > we have GA data for these links? That could help us decide. (need-info > Jbertsch) Yes. Let's keep those two links exposed at the top of /all

removing dependency bugs and moving them to the tracking bug#1268572

Fixed as part of Bug 1213372