Closed Bug 808762 Opened 12 years ago Closed 11 years ago

update Firefox languages page with new Sandstone design

Categories

(www.mozilla.org :: Pages & Content, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jslater, Assigned: sgarrity)

References

()

Details

(Whiteboard: u=user c=content p=2)

Attachments

(5 files)

As part of the ongoing Sandstonization of mozilla.org, we've updated the Firefox languages page. The PSD is here: 
http://cl.ly/1P3G0A380R2A

(note that the PSD doesn't display *all* of the languages that would be on the live page for time-saving purposes)

Mike, can you add this to the mozilla.org bug queue for an upcoming release?
Whiteboard: u=user c=content p=2
Depends on: 527907
The bug sgarrity linked to is asking to also show downloads for the 64 bits version for Linux. We need to check with product if we want to do that. But heads up, we might have to prepare for that. (And maybe also Windows 64 bits but that's not any time soon)
There is also http://www.mozilla.org/en-US/firefox/all-beta.html page that should probably be ported at the same time. I wondered if the design of this new page should be updated to reflect all three Firefox channels?
I'd really like to proceed with this update without being blocked by bug 527907 if possible. Isn't that something we could resolve after the new design is implemented? Otherwise, it could be awhile before things are worked out (that was nearly 300,000 bugs ago after all!).

Re: the beta page, I'm all for updating it but would again suggest doing a straight update rather than adding new functionality. (but I appreciate the question)

Thanks!
I've got a basic initial implementation of the template for this page setup in bedrock. For this first pass, I left a few of the elements, particularly the search box highlight, the form inputs, and the table styles as the default sandstone styles from the Style Guide.  See the attached screenshot to get an idea of how it compares to the PSD mockup (https://bug805429.bugzilla.mozilla.org/attachment.cgi?id=678415).

I'm fine with page-specific deviations from the style guide, but did want to confirm that they are wanted/necessary in this case.

Dropping the sidebar probably also requires re-thinking the way the language search works. On the old page (http://mozilla.org/firefox/all), the search results show below in the search form in the right sidebar. In this new design, I suspect it would be better to filter the main table of locales based on the search.

I'll be getting help from one of the python developers with the implementation of actual build data, given that this is now on bedrock.
Assignee: malexis → steven
(In reply to John Slater from comment #3)
> I'd really like to proceed with this update without being blocked by bug
> 527907 if possible. Isn't that something we could resolve after the new
> design is implemented? Otherwise, it could be awhile before things are
> worked out (that was nearly 300,000 bugs ago after all!).
> 
> Re: the beta page, I'm all for updating it but would again suggest doing a
> straight update rather than adding new functionality. (but I appreciate the
> question)
> 
> Thanks!
Yes, we should not wait on the decision in the other bug. We were just pointing at this in case that would help inform a design that works with several builds per platform.
Steven, following up from comment #4, it sounds like you and Lee were able to work out the details over IRC? Let me know if you still have questions or need guidance here.

Thanks!
I'll carry on with the linux x86_64 support once the new version of the page is released.
I also wanted to point out that the current version of the "Systems and languages" page had support for displaying a "Not yet released" message if a language was not available for a specific platform (not too common, I think). I don't see that reflected in the mockup.

Will that still be supported? Will the link offered revert to en-US in those cases?
Depends on: 811762
(In reply to Steven Garrity from comment #4)
> I'll be getting help from one of the python developers with the
> implementation of actual build data, given that this is now on bedrock.

Working version with front and back-end searching is in my branch. Pull my changes into yours and continue working or let me know if we're done and I'll submit the PR.

https://github.com/pmclanahan/bedrock/tree/bug-808762-firefox-all
Blocks: 817121
This is now available for review on https://www-demo3.allizom.org/b/en-US/firefox/all/
Looks really nice, thanks Steven.
There is a feature on the current all.html page that we no longer have on the new bersion, the possibility to link to a specific language, /ex:
http://www.mozilla.org/en-US/firefox/all.html#fr
(In reply to Pascal Chevrel:pascalc from comment #11)
> There is a feature on the current all.html page that we no longer have on
> the new bersion, the possibility to link to a specific language, /ex:
> http://www.mozilla.org/en-US/firefox/all.html#fr

That's easy to add to the new page, but I see no UI through which you could get at these. I'm sure they're useful, but I doubt many people know about them.
(In reply to Paul McLanahan [:pmac] from comment #12)
> (In reply to Pascal Chevrel:pascalc from comment #11)
> > There is a feature on the current all.html page that we no longer have on
> > the new bersion, the possibility to link to a specific language, /ex:
> > http://www.mozilla.org/en-US/firefox/all.html#fr
> 
> That's easy to add to the new page, but I see no UI through which you could
> get at these. I'm sure they're useful, but I doubt many people know about
> them.

We use them when we have new locales we want to promote but don't have pages yet for that locale. I don't know if it is widely used, I expect that some people in the l10n community use those links though, so if it can't make the first iteration, maybe it would be a good idea to add that feature (or an equivalent) back in a future version.
This page should be ready for QA: https://www-demo1.allizom.org/b/en-US/firefox/all/
Keywords: qawanted
1. at least in IE 7, clicking the "Search" button doesn't work
2. in IE 8, the error message isn't inline-aligned; it's vertical (see screenshot)
3. we don't validate according to our doctype; should we? http://validator.w3.org/unicorn/check?ucn_uri=https%3A%2F%2Fwww-demo1.allizom.org%2Fb%2Fen-US%2Ffirefox%2Fall%2F&ucn_task=conformance#

Sorry, will have more later, likely.
 (In reply to Stephen Donner [:stephend] from comment #15)
> 1. at least in IE 7, clicking the "Search" button doesn't work
> 2. in IE 8, the error message isn't inline-aligned; it's vertical (see
> screenshot)
@Stephend: Because it was I who changed it into <caption>s I added a pull request to fix this width-issue here https://github.com/mozilla/bedrock/pull/528
(In reply to Stephen Donner [:stephend] from comment #15)
> 1. at least in IE 7, clicking the "Search" button doesn't work
Looking into this

> 2. in IE 8, the error message isn't inline-aligned; it's vertical (see
> screenshot)
Fixed.

> 3. we don't validate according to our doctype; should we?
> http://validator.w3.org/unicorn/check?ucn_uri=https%3A%2F%2Fwww-demo1.
> allizom.org%2Fb%2Fen-US%2Ffirefox%2Fall%2F&ucn_task=conformance#
We should, but all of these are either known issues with the broader templates, or bugs in the validator, so we're ok for now on this page.
(In reply to Stephen Donner [:stephend] from comment #15)
> 1. at least in IE 7, clicking the "Search" button doesn't work

This is fixed now too.
Depends on: 821006
4. The "Sign me up" button text is clipped in IE 7.
5. In IE 6, 7, and 8 (at least), simply clicking on "Sign me up" submits the form and gives you the "You must enter a valid email address" and "You must agree to the privacy policy" error messages.

BTW, we should probably capitalize "Privacy Policy" there, no?
(In reply to Stephen Donner [:stephend] from comment #22)
> 5. In IE 6, 7, and 8 (at least), simply clicking on "Sign me up" submits the
> form and gives you the "You must enter a valid email address" and "You must
> agree to the privacy policy" error messages.
> 
> BTW, we should probably capitalize "Privacy Policy" there, no?

It does the same in all browsers I think, though modern ones will stop with the html5 required messages. That is the submit button. We could make it only submit if the fields are visible. It'd be strange for someone to hit the button before filling anything in the field though, but I'm sure some do it that way.
:stephend also, do you see the same behavior on https://www.mozilla.org/en-US/ ? I think you should. This "sign me up" button and form is used all over the site. We may have larger issues.
(In reply to Paul McLanahan [:pmac] from comment #24)
> :stephend also, do you see the same behavior on
> https://www.mozilla.org/en-US/ ? I think you should. This "sign me up"
> button and form is used all over the site. We may have larger issues.

Indeed; happens in prod with the same browsers, that site, same behavior.

Ditto for the button-text clipping issue I mentioned in comment 20, on prod (homepage).
I've filed Bug 821094 for the clipping submit button in IE and Bug 821099 for the form submission behaviour.

Can we decouple those issues from this page, as they are a problem on any page on the site?
(In reply to Steven Garrity from comment #26)
> I've filed Bug 821094 for the clipping submit button in IE and Bug 821099
> for the form submission behaviour.
> 
> Can we decouple those issues from this page, as they are a problem on any
> page on the site?

We sure can.  And, sorry, scattered availability, but found another couple issues on IE 9:

6. No pre-filled "Search languages" text in the textfield (minor)
Commit pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/b086b4a9d58e1dff085ff2fead63157945e6a4ce
Bug 808762: Port firefox/all/ page to bedrock.

New design for page.
As I mentioned in comment #7, the old version of all.html supported unavailable builds for a locale. The current bedrock version crashes in product details doesn't contain a platform (e.g. 17.0.1 Linux for ukranian), which is probably not desired.

I have created a patch which adds support for missing platforms and properly displays them with an icon and an 'Unavailable' text. You can find it at https://github.com/Elideb/bedrock/tree/all-html
Adding this would be really helpful to later integrate my patches for Linux64 builds, since we can add them in the page without depending on updating all entries in product details.
My changes also include a new macro in all.html to streamline the display of download icons for each platform.
Should I create a new bug to request support for Unavailable and make a pull request with an appropriately named branch, or can this small changes be pulled right away into bedrock's master?
(In reply to Elideb from comment #31)
> Should I create a new bug to request support for Unavailable and make a pull
> request with an appropriately named branch, or can this small changes be
> pulled right away into bedrock's master?

Thanks for the catch! I'd say this is a bug w/ the current implementation, and since it's in master perhaps a new bug is appropriate. A PR would be nice as well so we can do a proper code review.
I've created bug #827133 and created pull request https://github.com/mozilla/bedrock/pull/570
What is the status of this bug?
(In reply to Chris More [:cmore] from comment #34)
> What is the status of this bug?

Looks like we're in production http://www.mozilla.org/en-US/firefox/all/ and the new work by Elideb has a new bug. Closing.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Removed the PHP version of this page in SVN trunk in r112092.
Sign me up button is still clipped on IE7,
The HTML and text Radio buttons are also clipped . re-opening
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: