Bugzilla

Assignee

Comment 1

•

13 years ago

Here are some more notes I took from the elmo sprint in London

* We wait with twitter feed

* We aim to merge sub-head sentance with first top paragraph

* We build the list of teams as per wireframes
  (to see how that looks/feels on screen)

* We keep "Projects to localize" and inside list applications to
  localize
  (clicking on "Firefox" goes to Signoffs for the firefox-aurora
  AppVersion for example) and also mention things like Verbatim.

* Icons for applications will have to wait!
  * too hard to confidently/solidly get "sub-application" icons like
  Nightly, Thunderbird EarlyBird, etc.
  * Using the broad icons (e.g. Nightly gets the release Firefox logo)
  would be potentially confusing.

Reporter

Comment 2

•

13 years ago

Jeff, this is one of the first touchpoints between the dashboard and our broader communication pieces, you probably want to look at the url here and the notes.

Assignee

Comment 3

•

13 years ago

Note to self: the original design implementation was here: 
https://bugzilla.mozilla.org/show_bug.cgi?id=592515

Assignee

Comment 4

•

13 years ago

Attached patch New design implemented (obsolete) — Details — Splinter Review

The easiest way to review this is perhaps to first focus on the python changes around some of the python changes (for example, around the feed reader)
Then, to see if it works would be to click around on 
http://ec2-50-16-138-103.compute-1.amazonaws.com/

We will need to take a slight leap of faith to have this deployed on -dev- and just wait till all other bits and pieces are fully working and deploy when we're happy rather than based on calendar.

Attachment #579874 - Flags: review?(l10n)

Reporter

Comment 5

•

13 years ago

Comment on attachment 579874 [details] [diff] [review]
New design implemented

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

Worst comment first, I don't think that 960.gs is a good base choice :-(. It makes wide views hard to get right.

The dashboards are cut on the right on my local install, and views like dashboard/tree-status/ get a rather small data div.
The log-in box doesn't float to the right, but hangs somewhere in the free air (or not, it's right end is 960 from the left, I assume).

The comments on the files are on details, or on an overarching scheme of how to handle the feed. I'm torn on that one, but I really fear the blocking load. Depending on how to get out of there, different comments on the code apply slightly differently, I'd say.

More general notes:

header_content_extra doesn't make a good content area in my book in this design. It's looking really optional for the most part, so I'd only use it in exceptional cases.

::: apps/accounts/templates/accounts/login_form.html
@@ +58,5 @@
> +{% endfor %}
> +<button type="submit" class="button">OK</button>
> +{# {{ form }} #}
> +{#<ul>{{ form.as_ul }}<li><input type="submit" value="OK"></li></ul>#}
> +</form>

Curious, what does this buy us? I'd just like to see what we gain for the extra code.

::: apps/homepage/static/homepage/css/teams.css
@@ +35,5 @@
> + *
> + * ***** END LICENSE BLOCK ***** */
> +
> +#teams {
> +  -moz-column-width: 200px;

This is a text width right now, aka 35ex, and I think it makes much more sense that way.

::: apps/homepage/templates/homepage/locale-team.html
@@ +45,5 @@
>  {% endblock %}
> +
> +{% block header_h1 %}
> +Mozilla Localization Team {{ locale_name }}
> +<span class="lang">(ru-NS)</span>

oh? ru-NS? locale.code would be better :-)

::: apps/homepage/templates/homepage/teams.html
@@ +50,5 @@
>  {% endcompress %}
>  {% endblock %}
> +
> +{% block header_h1 %}Mozilla Localization Teams{% endblock %}
> +{% block header_content_extra %}<p>Find the different localization teams and the projects they work on on the pages beneath.</p>{% endblock %}

I'd move this back to content.

::: apps/homepage/test_rss20.xml
@@ +1,5 @@
> +<?xml version="1.0"?>
> +<rss version="2.0"
> +	xmlns:dc="http://purl.org/dc/elements/1.1/"
> +	xmlns:atom="http://www.w3.org/2005/Atom"
> +>

Make this less dramatic and smaller example data really? Shaver moving on from mozilla doesn't necessarily needs to be manifested in our test data.

::: apps/homepage/tests.py
@@ +71,4 @@
>          # arecibo server
>          settings.ARECIBO_SERVER_URL = 'http://arecibo/'
>  
> +        settings.L10N_FEED_URL = self._local_feed_url('test_rss20.xml')

I commented on the test data already, I wonder. Should we just abuse that feedparser doesn't mind getting plain content and set that here?

::: apps/homepage/views.py
@@ +82,5 @@
>  def index(request):
> +    split = 6
> +    locales = Locale.objects.filter(name__isnull=False).order_by('name')
> +
> +    feed_items = get_feed_items(5)

I'm not really comfortable that we have a blocking network call in the hot path here.

I'd rather see us do something async here, either by loading the div with the feed via ajax, or by going through celery to update the cached feed content.

::: apps/l10nstats/templates/l10nstats/tree_progress.html
@@ +98,1 @@
>  {% endcompress %}

This view is hosed, http://localhost:8000/dashboard/tree-status/fx_aurora on my setup has the histogram all fancy.

For this view, header_content_extra is actually good, IMHO. FYI.

::: apps/pushes/templates/pushes/pushlog.html
@@ -53,5 @@
>  <link rel="stylesheet" href="{{ STATIC_URL }}css/jquery.ui/base/ui.theme.css" type="text/css">
>  {% endcompress %}
> -{% compress css %}
> -<link rel="stylesheet" href="{{ STATIC_URL }}pushes/css/style-gitweb.css" type="text/css">
> -{% endcompress %}

Is this replaced with anything? I'm not really bound to that appearance, but there had been nice things like switching backgrounds on rows etc.

::: settings/base.py
@@ +297,5 @@
>    'compressor.finders.CompressorFinder',
>  )
>  
> +## Feeds
> +L10N_FEED_URL = 'http://planet.mozilla.org/l10n/atom.xml'#'http://planet.mozilla.org/rss20.xml'

I'd remove the reference to the global planet.

Also, it might be worthwhile to add a comment that one can enter plain data here for testing? See the test comments.

::: settings/local.py-dist
@@ +46,5 @@
>  #ARECIBO_SERVER_URL = "http://amckay-arecibo.khan.mozilla.org/"
>  
> +# Feed for example, to avoid having to do a HTTP call for the feed use:
> +#L10N_FEED_URL = 'file:///Users/peterbe/dev/MOZILLA/ELMO/elmo/apps/homepage/test_rss20.xml'
> +

... or make that here.

::: static/js/base.js
@@ +98,5 @@
> +               });
> +             }
> +           }
> +         });
> +         return false;

I disagree that your editor is doing something useful here, fwiw.

Not going to reverse engineer what this does.

::: static/simile/exhibit/exhibit-bundle.css
@@ +659,1 @@
>  .exhibit-tabularView-columnHeader {

I doubt this file should change at all. I guess this is your editor and the changes that you moved to dashboard.css?

::: templates/base.html
@@ +53,5 @@
> +	src: url('//www.mozilla.com/img/fonts/MetaWebPro-Bold.eot');
> +	src: local({% if debug %}'{{ STATIC_URL }}fonts/MetaWebPro-Bold.woff'{% else %}'☺'{% endif %}), url('//www.mozilla.com/img/fonts/MetaWebPro-Bold.woff') format('woff');
> +        font-weight: bold;
> +   }
> +   </style>

Should this be external?

Also, who licensed MetaWebPro for whom?

@@ +67,5 @@
> +				<input type="hidden" name="cx" value="002443141534113389537:ysdmevkkknw">
> +				<input type="hidden" name="cof" value="FORID:0">
> +				<input type="search" name="q" id="q" placeholder="Search"><input type="image" src="images/search-submit.png" alt="Search" id="quick-search-btn">
> +			</form>
> +			-->

Remove that instead of leaving keys and whatnot commented out?

@@ +73,5 @@
> +			<div id="auth">
> +				{% include "accounts/user_forms.html" %}
> +				<noscript>Not logged in</noscript>
> +<!--				<a href="homepage-login.html">Sign in</a> |
> +				<a href="">Register</a>-->

... same here.

@@ +114,5 @@
> +				<p>Except where otherwise <a href="">noted</a>, content on this site is licensed under the <a href="">Creative Commons Attribution Share-Alike License v3.0</a> or any later version. </p>
> +				<p class="notices"><a href="{% url privacy.views.show_policy %}">Privacy Policy</a> | <a href="">Legal Notices (XXX)</a></p>
> +			</div>
> +            <div id="template-bottom-background"></div>
> +		</footer>

Did we figure out where those links go? Rather not have XXX in there, as little as <!-- -->

::: vendor-local/lib/python/feedparser.py
@@ +3,5 @@
> +
> +Handles RSS 0.9x, RSS 1.0, RSS 2.0, CDF, Atom 0.3, and Atom 1.0 feeds
> +
> +Visit http://feedparser.org/ for the latest version
> +Visit http://feedparser.org/docs/ for the latest documentation

Feedparser moved to http://code.google.com/p/feedparser/, and there's a 5.1 now. I wouldn't mind much, if the old link wasn't dead broken.

Attachment #579874 - Flags: review?(l10n) → review-

Assignee

Comment 6

•

13 years ago

(In reply to Axel Hecht [:Pike] from comment #5)
> Comment on attachment 579874 [details] [diff] [review]
> New design implemented
> 
> Review of attachment 579874 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Worst comment first, I don't think that 960.gs is a good base choice :-(. It
> makes wide views hard to get right.
> 
OK. Can't do anything about that :)

> The dashboards are cut on the right on my local install, and views like
> dashboard/tree-status/ get a rather small data div.
> The log-in box doesn't float to the right, but hangs somewhere in the free
> air (or not, it's right end is 960 from the left, I assume).
> 

I'm going to describe the problem with the dashboard and the strange footer floating problem with the tree-status page to Schalk so he can hopefully fix it on my EC2 server. 

Regarding the Login, I don't think it's meant to float strictly to the right-hand edge. As far as I've understood, this is how it's supposed to be. 


> The comments on the files are on details, or on an overarching scheme of how
> to handle the feed. I'm torn on that one, but I really fear the blocking
> load. Depending on how to get out of there, different comments on the code
> apply slightly differently, I'd say.
> 
> More general notes:
> 
> header_content_extra doesn't make a good content area in my book in this
> design. It's looking really optional for the most part, so I'd only use it
> in exceptional cases.
> 

What do you suggest instead? I quite like it when it's filled in with something. Either way, let's let an expert decide once he/she is involved. 

> ::: apps/accounts/templates/accounts/login_form.html
> @@ +58,5 @@
> > +{% endfor %}
> > +<button type="submit" class="button">OK</button>
> > +{# {{ form }} #}
> > +{#<ul>{{ form.as_ul }}<li><input type="submit" value="OK"></li></ul>#}
> > +</form>
> 
> Curious, what does this buy us? I'd just like to see what we gain for the
> extra code.
> 
"Buy us"? That it works :)
I spent a lot of time making the login form work nicely with the new design. I have removed the commented-out code now. 


> ::: apps/homepage/static/homepage/css/teams.css
> @@ +35,5 @@
> > + *
> > + * ***** END LICENSE BLOCK ***** */
> > +
> > +#teams {
> > +  -moz-column-width: 200px;
> 
> This is a text width right now, aka 35ex, and I think it makes much more
> sense that way.
> 
What? Don't understand your point. Are you referring to replacing "200px" with "35ex"? 

> ::: apps/homepage/templates/homepage/locale-team.html
> @@ +45,5 @@
> >  {% endblock %}
> > +
> > +{% block header_h1 %}
> > +Mozilla Localization Team {{ locale_name }}
> > +<span class="lang">(ru-NS)</span>
> 
> oh? ru-NS? locale.code would be better :-)
> 
Well spotted!! That's what code reviews are for.

> ::: apps/homepage/templates/homepage/teams.html
> @@ +50,5 @@
> >  {% endcompress %}
> >  {% endblock %}
> > +
> > +{% block header_h1 %}Mozilla Localization Teams{% endblock %}
> > +{% block header_content_extra %}<p>Find the different localization teams and the projects they work on on the pages beneath.</p>{% endblock %}
> 
> I'd move this back to content.
> 

If I've understood you correctly, you want this to be managed *inside* the "content" block? That doesn't work. The content needs to appear instead the <div id="header-content"> area. 


> ::: apps/homepage/test_rss20.xml
> @@ +1,5 @@
> > +<?xml version="1.0"?>
> > +<rss version="2.0"
> > +	xmlns:dc="http://purl.org/dc/elements/1.1/"
> > +	xmlns:atom="http://www.w3.org/2005/Atom"
> > +>
> 
> Make this less dramatic and smaller example data really? Shaver moving on
> from mozilla doesn't necessarily needs to be manifested in our test data.
>

It's not just for unit testing. It's also for local runserver development. 
I did however now remove the Shaver item. 
 
> ::: apps/homepage/tests.py
> @@ +71,4 @@
> >          # arecibo server
> >          settings.ARECIBO_SERVER_URL = 'http://arecibo/'
> >  
> > +        settings.L10N_FEED_URL = self._local_feed_url('test_rss20.xml')
> 
> I commented on the test data already, I wonder. Should we just abuse that
> feedparser doesn't mind getting plain content and set that here?
> 
I'd rather not. We demonstrate it better by using a URL. 

> ::: apps/homepage/views.py
> @@ +82,5 @@
> >  def index(request):
> > +    split = 6
> > +    locales = Locale.objects.filter(name__isnull=False).order_by('name')
> > +
> > +    feed_items = get_feed_items(5)
> 
> I'm not really comfortable that we have a blocking network call in the hot
> path here.
> 
> I'd rather see us do something async here, either by loading the div with
> the feed via ajax, or by going through celery to update the cached feed
> content.
> 

It is cached for an hour every time after all. Introducing, celery right now would be fun but would block the release of this even further. 

If you like, we could set up an hourly cron job that does something like::

  curl https://l10n.mozilla.org/?FORCE_FEED_REFRESH=true

That way, it becomes less likely that a human user kicks off the potentially slow network process. 
Bear in mind that the feed on is on pretty decent hardware and does work very reliably. 

My suggestion is to iterate this with a follow up later with a proper celery based solution.  


> ::: apps/l10nstats/templates/l10nstats/tree_progress.html
> @@ +98,1 @@
> >  {% endcompress %}
> 
> This view is hosed, http://localhost:8000/dashboard/tree-status/fx_aurora on
> my setup has the histogram all fancy.
> 

"all fancy"?
Either way, I'm going to dump this problem on Schalk and he can hopefully solve it. 

> For this view, header_content_extra is actually good, IMHO. FYI.
> 
> ::: apps/pushes/templates/pushes/pushlog.html
> @@ -53,5 @@
> >  <link rel="stylesheet" href="{{ STATIC_URL }}css/jquery.ui/base/ui.theme.css" type="text/css">
> >  {% endcompress %}
> > -{% compress css %}
> > -<link rel="stylesheet" href="{{ STATIC_URL }}pushes/css/style-gitweb.css" type="text/css">
> > -{% endcompress %}
> 
> Is this replaced with anything? I'm not really bound to that appearance, but
> there had been nice things like switching backgrounds on rows etc.
> 

I don't think it's replaced. If you think we really need the odd/even background coloring I can put that in. 

> ::: settings/base.py
> @@ +297,5 @@
> >    'compressor.finders.CompressorFinder',
> >  )
> >  
> > +## Feeds
> > +L10N_FEED_URL = 'http://planet.mozilla.org/l10n/atom.xml'#'http://planet.mozilla.org/rss20.xml'
> 
> I'd remove the reference to the global planet.
> 
Gone.

> Also, it might be worthwhile to add a comment that one can enter plain data
> here for testing? See the test comments.
> 
> ::: settings/local.py-dist
> @@ +46,5 @@
> >  #ARECIBO_SERVER_URL = "http://amckay-arecibo.khan.mozilla.org/"
> >  
> > +# Feed for example, to avoid having to do a HTTP call for the feed use:
> > +#L10N_FEED_URL = 'file:///Users/peterbe/dev/MOZILLA/ELMO/elmo/apps/homepage/test_rss20.xml'
> > +
> 
> ... or make that here.
>
Instead of that absolute url, I'm going to replace that with a little `os.path(...)` trick so that you can enable the same local feed url without having to s/peterbe/Pike
 
> ::: static/js/base.js
> @@ +98,5 @@
> > +               });
> > +             }
> > +           }
> > +         });
> > +         return false;
> 
> I disagree that your editor is doing something useful here, fwiw.
> 
> Not going to reverse engineer what this does.
> 
Next time, I'll make a diff that ignores whitespace. 

> ::: static/simile/exhibit/exhibit-bundle.css
> @@ +659,1 @@
> >  .exhibit-tabularView-columnHeader {
> 
> I doubt this file should change at all. I guess this is your editor and the
> changes that you moved to dashboard.css?
> 
Reverted.

> ::: templates/base.html
> @@ +53,5 @@
> > +	src: url('//www.mozilla.com/img/fonts/MetaWebPro-Bold.eot');
> > +	src: local({% if debug %}'{{ STATIC_URL }}fonts/MetaWebPro-Bold.woff'{% else %}'☺'{% endif %}), url('//www.mozilla.com/img/fonts/MetaWebPro-Bold.woff') format('woff');
> > +        font-weight: bold;
> > +   }
> > +   </style>
> 
> Should this be external?
> 
Apparently. It's considered unsafe to use a local font. Hence that smiley character. 
The reason for the `if debug` trick in there is to use the local when doing development. 

> Also, who licensed MetaWebPro for whom?
> 
Don't know. Suggestions?

> @@ +67,5 @@
> > +				<input type="hidden" name="cx" value="002443141534113389537:ysdmevkkknw">
> > +				<input type="hidden" name="cof" value="FORID:0">
> > +				<input type="search" name="q" id="q" placeholder="Search"><input type="image" src="images/search-submit.png" alt="Search" id="quick-search-btn">
> > +			</form>
> > +			-->
> 
> Remove that instead of leaving keys and whatnot commented out?
> 
Gone.

> @@ +73,5 @@
> > +			<div id="auth">
> > +				{% include "accounts/user_forms.html" %}
> > +				<noscript>Not logged in</noscript>
> > +<!--				<a href="homepage-login.html">Sign in</a> |
> > +				<a href="">Register</a>-->
> 
> ... same here.
> 
Gone.

> @@ +114,5 @@
> > +				<p>Except where otherwise <a href="">noted</a>, content on this site is licensed under the <a href="">Creative Commons Attribution Share-Alike License v3.0</a> or any later version. </p>
> > +				<p class="notices"><a href="{% url privacy.views.show_policy %}">Privacy Policy</a> | <a href="">Legal Notices (XXX)</a></p>
> > +			</div>
> > +            <div id="template-bottom-background"></div>
> > +		</footer>
> 
> Did we figure out where those links go? Rather not have XXX in there, as
> little as <!-- -->
> 

There's another bug on that. #707808
I made this bug block that one. I think we actually nailed in it a meeting so cracking #707808 should be easy. 

> ::: vendor-local/lib/python/feedparser.py
> @@ +3,5 @@
> > +
> > +Handles RSS 0.9x, RSS 1.0, RSS 2.0, CDF, Atom 0.3, and Atom 1.0 feeds
> > +
> > +Visit http://feedparser.org/ for the latest version
> > +Visit http://feedparser.org/docs/ for the latest documentation
> 
> Feedparser moved to http://code.google.com/p/feedparser/, and there's a 5.1
> now. I wouldn't mind much, if the old link wasn't dead broken.

I'm apprehensive about manually fiddling with code I installed from pypi. 
Do you think I should just do a plain edit of those URLs and pretend it came like that? Let me know.

Blocks: 707808

Assignee

Comment 7

•

13 years ago

Attached patch More design fixes (obsolete) — Details — Splinter Review

The problem with the right-side chopped off dashboard and the floating legend boxes on the tree-status page has all been fixed. 

Also, various other fixes as per my last comment addressed. Some unresolved arguments in my latest response not resolved.

Attachment #579874 - Attachment is obsolete: true

Attachment #585774 - Flags: review?(l10n)

Reporter

Comment 8

•

13 years ago

(In reply to Peter Bengtsson [:peterbe] from comment #6)

I'll look at the new patch again, but some answers to comment 6 right away:

> 
> > ::: apps/homepage/static/homepage/css/teams.css
> > @@ +35,5 @@
> > > + *
> > > + * ***** END LICENSE BLOCK ***** */
> > > +
> > > +#teams {
> > > +  -moz-column-width: 200px;
> > 
> > This is a text width right now, aka 35ex, and I think it makes much more
> > sense that way.
> > 
> What? Don't understand your point. Are you referring to replacing "200px"
> with "35ex"? 

Yes, which is what it is right now. The idea is that language names fit in one line, thus the amount of characters matter much more than pixels or visual width.

> > ::: templates/base.html
> > @@ +53,5 @@
> > > +	src: url('//www.mozilla.com/img/fonts/MetaWebPro-Bold.eot');
> > > +	src: local({% if debug %}'{{ STATIC_URL }}fonts/MetaWebPro-Bold.woff'{% else %}'☺'{% endif %}), url('//www.mozilla.com/img/fonts/MetaWebPro-Bold.woff') format('woff');
> > > +        font-weight: bold;
> > > +   }
> > > +   </style>
> > 
> > Should this be external?
> > 
> Apparently. It's considered unsafe to use a local font. Hence that smiley
> character. 
> The reason for the `if debug` trick in there is to use the local when doing
> development. 

I'm confused that local() would be something file-path-y or so? Also, why reference one or the other?

> > Also, who licensed MetaWebPro for whom?
> > 
> Don't know. Suggestions?

Nope, where is that text coming from? Apparently we need a license, and I don't know if we have one.

> > ::: vendor-local/lib/python/feedparser.py
> > @@ +3,5 @@
> > > +
> > > +Handles RSS 0.9x, RSS 1.0, RSS 2.0, CDF, Atom 0.3, and Atom 1.0 feeds
> > > +
> > > +Visit http://feedparser.org/ for the latest version
> > > +Visit http://feedparser.org/docs/ for the latest documentation
> > 
> > Feedparser moved to http://code.google.com/p/feedparser/, and there's a 5.1
> > now. I wouldn't mind much, if the old link wasn't dead broken.
> 
> I'm apprehensive about manually fiddling with code I installed from pypi. 
> Do you think I should just do a plain edit of those URLs and pretend it came
> like that? Let me know.

pypi has 5.1 now, with google code links.

Assignee

Comment 9

•

13 years ago

(In reply to Axel Hecht [:Pike] from comment #8)
> (In reply to Peter Bengtsson [:peterbe] from comment #6)
> 
> I'll look at the new patch again, but some answers to comment 6 right away:
> 
> > 
> > > ::: apps/homepage/static/homepage/css/teams.css
> > > @@ +35,5 @@
> > > > + *
> > > > + * ***** END LICENSE BLOCK ***** */
> > > > +
> > > > +#teams {
> > > > +  -moz-column-width: 200px;
> > > 
> > > This is a text width right now, aka 35ex, and I think it makes much more
> > > sense that way.
> > > 
> > What? Don't understand your point. Are you referring to replacing "200px"
> > with "35ex"? 
> 
> Yes, which is what it is right now. The idea is that language names fit in
> one line, thus the amount of characters matter much more than pixels or
> visual width.
>
Changed back to 35ex. 
 
> > > ::: templates/base.html
> > > @@ +53,5 @@
> > > > +	src: url('//www.mozilla.com/img/fonts/MetaWebPro-Bold.eot');
> > > > +	src: local({% if debug %}'{{ STATIC_URL }}fonts/MetaWebPro-Bold.woff'{% else %}'☺'{% endif %}), url('//www.mozilla.com/img/fonts/MetaWebPro-Bold.woff') format('woff');
> > > > +        font-weight: bold;
> > > > +   }
> > > > +   </style>
> > > 
> > > Should this be external?
> > > 
> > Apparently. It's considered unsafe to use a local font. Hence that smiley
> > character. 
> > The reason for the `if debug` trick in there is to use the local when doing
> > development. 
> 
> I'm confused that local() would be something file-path-y or so? Also, why
> reference one or the other?
> 
> > > Also, who licensed MetaWebPro for whom?
> > > 
> > Don't know. Suggestions?
> 
> Nope, where is that text coming from? Apparently we need a license, and I
> don't know if we have one.
> 
I'll see if Adrian (who wrote it originally) can help regarding the licensing stuff. 

Also, the reason for the local() stuff is that for production use we never want local() to work but we want it for us who can trust the code. Makes our work easier (not having to rely on the network) and our users safe. 

> > > ::: vendor-local/lib/python/feedparser.py
> > > @@ +3,5 @@
> > > > +
> > > > +Handles RSS 0.9x, RSS 1.0, RSS 2.0, CDF, Atom 0.3, and Atom 1.0 feeds
> > > > +
> > > > +Visit http://feedparser.org/ for the latest version
> > > > +Visit http://feedparser.org/docs/ for the latest documentation
> > > 
> > > Feedparser moved to http://code.google.com/p/feedparser/, and there's a 5.1
> > > now. I wouldn't mind much, if the old link wasn't dead broken.
> > 
> > I'm apprehensive about manually fiddling with code I installed from pypi. 
> > Do you think I should just do a plain edit of those URLs and pretend it came
> > like that? Let me know.
> 
> pypi has 5.1 now, with google code links.

Updated in the latest patch.

[DEACTIVATED] Adrian Gaudebert

Assignee

Comment 10

•

13 years ago

Attached patch latest fixes (obsolete) — Details — Splinter Review

This fixes:

* 35ex instead of 200px

* latest feedparser from google code

* a refresh_feeds [1] that a cron job can pull every hour to assure the cache is always filled with the latest feed stuff

[1] Reason for calling it pluralized "refresh_feedS" is that we might later have more functions in there that we want to refresh periodically.

Attachment #585774 - Attachment is obsolete: true

Attachment #585774 - Flags: review?(l10n)

Attachment #586273 - Flags: review?(l10n)

Comment 11

•

13 years ago

(In reply to Peter Bengtsson [:peterbe] from comment #9)
> I'll see if Adrian (who wrote it originally) can help regarding the
> licensing stuff. 

Well, I actually just took what we are using on mozilla.org. Just have a look at the source code of http://www.mozilla.org/ and you will find that exact same font. I have no idea what the licensing is though, I assumed we had the right to use it but I may have been wrong... Maybe someone working on mozilla.org knows better?

Reporter

Comment 12

•

13 years ago

OK, I found the local smiley thing, that's http://paulirish.com/2009/bulletproof-font-face-implementation-syntax/#smiley and keeps IE from loading the font it can't read. There should not be any DEBUG stuff in there, I think.

I'll file a seperate bug to confirm how we're supposed to use that, blocking this one.

Reporter

Updated

•

13 years ago

Depends on: 715875

Reporter

Comment 13

•

13 years ago

Comment on attachment 586273 [details] [diff] [review]
latest fixes

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

I'll cancel the review request here, as we know that there are outstanding visual regressions still.

I like the command that we have now, but I still want us to go bolder a bit on relying on it.

::: apps/homepage/views.py
@@ +99,5 @@
> +    cache_key = 'feed_items:%s' % max_count
> +    if not force_refresh:
> +        items = cache.get(cache_key, None)
> +        if items is not None:
> +            return items

I think we should force the view to only ever return the cache, or an empty list. Not sure if there's more to factor, then. Maybe it's better to move the getter and setter of the cache into a utils.py?

::: scripts/update_site.py
@@ +31,4 @@
>  NASHVEGAS_EXEC = "./manage.py upgradedb --path migrations --execute"
>  STATICFILES_COLLECT_EXEC = "./manage.py collectstatic --noinput"
>  DJANGOCOMPRESSOR_COMPRESS_EXEC = "./manage.py compress"
> +REFRESH_FEEDS_EXEC = "./manage.py refresh_feeds -v 2"

I don't think we should pipe feed items into IT's face whenever they update the site ?

::: settings/local.py-dist
@@ +46,5 @@
>  # if you want to test the Arecibo
>  #ARECIBO_SERVER_URL = "http://amckay-arecibo.khan.mozilla.org/"
>  
> +# Feed for example, to avoid having to do a HTTP call for the feed use:
> +#L10N_FEED_URL = 'file:///Users/peterbe/dev/MOZILLA/ELMO/elmo/apps/homepage/test_rss20.xml'

In comment 6 you promised some path magic that you wanted to do instead of hard-coding this?

Attachment #586273 - Flags: review?(l10n)

Comment 14

•

12 years ago

Attached image Home page header one — Details

Which header do you prefer in terms of bottom spacing, this one?

Comment 15

•

12 years ago

Attached image Home page header two — Details

or this one?

Reporter

Comment 16

•

12 years ago

(In reply to Schalk Neethling from comment #14)
> Created attachment 591418 [details]
> Home page header one
> 
> Which header do you prefer in terms of bottom spacing, this one?

I think I prefer this one.

Jeff Beatty [:gueroJeff]

Comment 17

•

12 years ago

(In reply to Axel Hecht [:Pike] from comment #16)
> (In reply to Schalk Neethling from comment #14)
> > Created attachment 591418 [details]
> > Home page header one
> > 
> > Which header do you prefer in terms of bottom spacing, this one?
> 
> I think I prefer this one.

I second Pike.

Assignee

Comment 18

•

12 years ago

(In reply to Axel Hecht [:Pike] from comment #16)
> (In reply to Schalk Neethling from comment #14)
> > Created attachment 591418 [details]
> > Home page header one
> > 
> > Which header do you prefer in terms of bottom spacing, this one?
> 
> I think I prefer this one.

Me too.

Reporter

Comment 19

•

12 years ago

Side note: for the cron job to update the planet feed, we should be good with 10, 25, 40, 55, i.e. every 15 minutes with some offset to when the l10n planet finishes.

Reporter

Updated

•

12 years ago

Blocks: 716604

Assignee

Updated

•

12 years ago

Blocks: 715600

Comment 21

•

12 years ago

1) I love how media queries are used to hide the blog roll (on the right)
and how side-by-side blocks are reduced to be over and below each other
when you resize to a smaller window.
But the header fails quiet badly.
http://cl.ly/2J3b2v1D2k2O183b2t0f
http://cl.ly/0c2f0X3o2Z2n3P36180B

2) We have a bug in the HTML of the dashboard page. Might be unrelated to
the new design work
http://cl.ly/333y0u1R2Z2r1p341c0I

3) There's a strange whitespace indentation around "Jeff Griffiths" name.
Looked in the HTML and there's no whitespace between the ">" and "Jeff"
http://cl.ly/102H0Q2Z2T0A0o373F25

4) I thought we had agreed to use more generic solutions for exceptions.
Ie. instead of class="page-dashboard" we use class="page-wider" and put
the relevant CSS in style.css instead of dashboard.css. That way other
extreme pages can get the same love that the dashboard gets but without
having to references it as "dashboard".

5) On the teams page, whilst we're at it. Can you arrange so that the
first column in every table is fixed width so that they all line up nicely.
I guess you need to figure out which Tree name is the longest and add
some padding for the future and then make sure the rest of the table
doesn't get screwed up
http://cl.ly/303F0P0p440w1L3F3k3J

Comment 22

•

12 years ago

1) fixed
2) fixed

Comment 23

•

12 years ago

3) where is the data for this coming from?

Reporter

Comment 24

•

12 years ago

Re 5, from bug 696446 comment 10, http://cl.ly/0r2M0G2M0C3r3t1i1V0p is what we're heading for. Not sure how we'll implement that, but the section heading should be closer to a table group.

Comment 25

•

12 years ago

Pull request sent for issue 1 and a second pull request for issue 2 is awaiting the merge of the current pull request. 

On item three, I initial had a rule such as this:

.page-wider,
.page-dashboard {
    width: 1030px;
}

The reason was I did not want to break any other style rules that might rely on page-dashboard existing. I looked over dashboard.css and style.css and do no find any other references so, I have dropped the page-dashboard rule and I am only keeping page-wider

Comment 26

•

12 years ago

[:peterbe] Nothing is waiting on a merge, all commits so far are in the same pull request

Comment 27

•

12 years ago

[:peterbe] Sent pull request for last couple of fixes. I have more suggestions regarding the individual teams page but, perhaps we can take what there is now and push this and then continue after.

Assignee

Comment 28

•

12 years ago

Still buggy :(

When resizing, at certain widths the header just disappears into the left. 
Now both on the home page and the /privacy page
http://cl.ly/1m0j1Z3h132D0r2Y0B11
http://cl.ly/3F3f2Z0y2h1H402T3H46

Otherwise, the teams page looks great! You did a really good job there with the tables.

Comment 29

•

12 years ago

[:peterbe] Yeah it is a very fine line where it is at now, the reason it is pushing out on the left and then snapping back at 960px is because of the 1100px min width on the header container.

We need that because the body is specified in pixels and if the min-width is removed, we have the previous situation where, when you resize the window, the content extends past the header at times.

I will look into this though some more as well as the rewrite of the header/footer as discussed on IRC.

Comment 30

•

12 years ago

Two questions:

Why do we not simply hide the 'blogroll' when we reach the 960 cut off? As I ask this question I just want to also add the my latest pull request does do this and I would love some feedback.

Second thing, are we concerned about the effects of the media queries on pages such as shipping/dashboard or are those a situation where we do not foresee anyone using those pages on a small screen?

Comment 31

•

12 years ago

New pull request sent for remaining tweaks :: https://github.com/peterbe/elmo/pull/5

Assignee

Comment 32

•

12 years ago

Attached patch Final patch (obsolete) — Details — Splinter Review

*This has all the latest and greatest fixes from Schalk. 

*It makes the tree-status and history page also "wider pages".

* The correction of "Signoff(s)" --> "Sign-off(s)" has been cherry picked in

* All tests pass

* The home page can fetch from the network if it needs to (hopefully the cron job will minimize this)

* The settings/local.py-dist suggests a way to reference a local feed fixture without hardcoding the full path

* The fonts are now properly local instead of being served from www.mozilla.org
** No more silly hacks needed for local debug development. The smiley is back!

* The update_site.py will refresh the feed but not in verbose mode.

Attachment #586273 - Attachment is obsolete: true

Attachment #597071 - Flags: review?(l10n)

Reporter

Comment 33

•

12 years ago

Comment on attachment 597071 [details] [diff] [review]
Final patch

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

This is a great step forward, awesome work you guys.

There's still a bit of stuff to figure out, see the comments below:

dashboard/tree-status/foo is having issues with the histogram and the legend. The histogram shouldn't fill the width of the content div, and the legend should float. I haven't fully figured out what is what.

I'm going for an r- for the "can't follow the wiki link", and the histogram to some extent.

::: apps/homepage/management/commands/refresh_feeds.py
@@ +36,5 @@
> +"""This managment commands runs all the functions again that pull feeds (parses
> +them and stores its results in a cache).
> +
> +Ideally this management command should be run every hour. That prevents the
> +home page view from having to block on network problems.

Change this to

Ideally this management command should run in sync with the update job on planet, but at least every hour.

?

::: apps/homepage/templates/homepage/index.html
@@ +165,5 @@
> +		<p><a href="">Sed nec lacus a turpis consequat fermentum eu eget felis. </a></p>
> +		<p><a href="">Curabitur nisi mauris, gravida volutpat ullamcorper sit amet, congue in dui. </a></p>
> +		<p><a href="">Nulla vel sapien vitae urna ullamcorper rutrum!</a></p>
> +	</section>
> +	{% endcomment %}

Remove this block? Maybe add a comment to just mention that another section could be a twitter feed.

Best way to do that is probably to just file a bug on adding that, and reference the bug in the comment.

::: apps/homepage/templates/homepage/locale-team.html
@@ +57,5 @@
> +{% endblock %}
> +
> +{% block header_content_extra %}
> +<p>Contact the team on it's page on <a href="https://wiki.mozilla.org/L10n:Teams:{{locale.code}}">wikimo</a>.</p>
> +{% endblock %}

Please move this into the main content and out of the the extra header content?

We need this to be visible, and also, it solves the click jacking problem of the div.

::: apps/homepage/templates/homepage/teams.html
@@ +58,3 @@
>  <p class="highlight"><em>Don't find your Language?</em> You may want to check the list of
>  <a href="https://wiki.mozilla.org/L10n:Teams">existing and upcoming teams</a> on our wiki, or
>  <a href="https://developer.mozilla.org/en/Create_a_new_localization">start a new localization</a>.</p>

While you're at it, can you change this to https://developer.mozilla.org/en/Localization_Quick_Start_Guide ? The other link goes straight to an MDN edit as that page doesn't exist anymore :-/

::: apps/homepage/views.py
@@ +91,5 @@
> +      'feed_items': feed_items,
> +      'locales_first_half': locales[:split],
> +      'locales_second_half': locales[split:split * 2 - 1],
> +      'locales_rest_count': locales.count() - split * 2 - 1,
> +    }

I'd prefer if we could do the locales query in one go, and just slice the resulting list.

Also, for demo setups with 3 locales, we probably don't want negative rest counts? Either fix that here or in the template to only show that link if there's more than 0?

::: apps/l10nstats/static/l10nstats/css/tree_progress.css
@@ +56,5 @@
> +
> +.legend {
> +    float: none !important;
> +    margin-top: 10px;
> +}

the float:none directly conflicts with the explicit style attr in the template,
<div class="legend" style="float:right">

::: apps/pushes/templates/pushes/pushlog.html
@@ -45,5 @@
>  <link rel="stylesheet" href="{{ STATIC_URL }}css/jquery.ui/smoothness/jquery-ui-1.8.16.custom.css" type="text/css">
>  {% endcompress %}
> -{% compress css %}
> -<link rel="stylesheet" href="{{ STATIC_URL }}pushes/css/style-gitweb.css" type="text/css">
> -{% endcompress %}

Now that we don't use that file anymore, it should be git removed, I guess.

::: apps/shipping/static/shipping/css/snippet.css
@@ +80,1 @@
>      }

hard-coding the width here sounds wrong. both that it's in px, when it's trying to align text, but also it should at least be a min-width, so that if we get an overflowing tree name, things still show.

A min-width in ex or so sounds much more like it.

::: requirements/prod.txt
@@ +10,1 @@
>  

Should we have a follow-up bug to make all of these have explicit versions?

::: settings/local.py-dist
@@ +46,5 @@
>  # if you want to test the Arecibo
>  #ARECIBO_SERVER_URL = "http://amckay-arecibo.khan.mozilla.org/"
>  
> +# Feed for example, to avoid having to do a HTTP call for the feed use:
> +#L10N_FEED_URL = 'file://' + os.path.abspath('apps/homepage/test_rss20.xml')

is that fool-proof of starting elmo in non-standard directories, if that even works? wondering if some os.path.dirname(__file__) or something to make sure we get the right basepath would be at order?

::: static/css/style.css
@@ +1,1 @@
> +/*  Reset */

Nit, I don't know how many of the rules below are actually reset, and when we actually start a non-reset stylesheet.

Of course, I don't grok css reset to begin with :-(.

@@ +163,5 @@
> +body#home > header {
> +    height: auto;
> +}
> +
> +/* new header */

Oy, header and new header? Just sayin', I bet most of this stuff is copied over from mozilla.org history.

@@ +525,5 @@
> +/* Media Queries */
> +/* Small screens */
> +@media (max-width: 960px) {
> +
> +    /* { border: 1px solid red; }*/

debug? remove.

::: templates/base.html
@@ +50,5 @@
> +    /* MetaWebPro font family licensed from fontshop.com. WOFF-FTW! */
> +    @font-face {
> +        font-family: 'MetaBold';
> +	src: url('{{ STATIC_URL }}fonts/MetaWebPro-Bold.eot');
> +	src: local('☺'), url('{{ STATIC_URL }}fonts/MetaWebPro-Bold.woff') format('woff');

sharing the font from mozilla.org didn't work after all? Cool with me, just checking.

Attachment #597071 - Flags: review?(l10n) → review-

Assignee

Comment 34

•

12 years ago

(In reply to Axel Hecht [:Pike] from comment #33)
> Comment on attachment 597071 [details] [diff] [review]
> Final patch
> 
> Review of attachment 597071 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> This is a great step forward, awesome work you guys.
> 
> There's still a bit of stuff to figure out, see the comments below:
> 
> dashboard/tree-status/foo is having issues with the histogram and the
> legend. The histogram shouldn't fill the width of the content div, and the
> legend should float. I haven't fully figured out what is what.
> 
> I'm going for an r- for the "can't follow the wiki link", and the histogram
> to some extent.
> 
> ::: apps/homepage/management/commands/refresh_feeds.py
> @@ +36,5 @@
> > +"""This managment commands runs all the functions again that pull feeds (parses
> > +them and stores its results in a cache).
> > +
> > +Ideally this management command should be run every hour. That prevents the
> > +home page view from having to block on network problems.
> 
> Change this to
> 
> Ideally this management command should run in sync with the update job on
> planet, but at least every hour.
> 
> ?
Sure but I'm not sure it's clear. What is the "sync with update job on planet". That's run by someone/something else and we don't know if they update every 15min, 60min or 24 hours. 

Anyway, if we could actually find out we'll just set our cron job to the same value. Who would know?

> 
> ::: apps/homepage/templates/homepage/index.html
> @@ +165,5 @@
> > +		<p><a href="">Sed nec lacus a turpis consequat fermentum eu eget felis. </a></p>
> > +		<p><a href="">Curabitur nisi mauris, gravida volutpat ullamcorper sit amet, congue in dui. </a></p>
> > +		<p><a href="">Nulla vel sapien vitae urna ullamcorper rutrum!</a></p>
> > +	</section>
> > +	{% endcomment %}
> 
> Remove this block? Maybe add a comment to just mention that another section
> could be a twitter feed.
> 
Yanked! It was kept with optimisim of this soon becoming a feature we might support. However, the HTML that was commented out has already become obsolete. 

> Best way to do that is probably to just file a bug on adding that, and
> reference the bug in the comment.
> 
Truth is, we decided not to do it. I don't want to file a bug when it's not a bug and not something I can work on. 
Let's return to the subject some time soon in a meeting. 

 

> ::: apps/homepage/templates/homepage/locale-team.html
> @@ +57,5 @@
> > +{% endblock %}
> > +
> > +{% block header_content_extra %}
> > +<p>Contact the team on it's page on <a href="https://wiki.mozilla.org/L10n:Teams:{{locale.code}}">wikimo</a>.</p>
> > +{% endblock %}
> 
> Please move this into the main content and out of the the extra header
> content?
> 
> We need this to be visible, and also, it solves the click jacking problem of
> the div.
> 
Roger that. Moved now. I also changed the "Back to all teams" link not be a small font. 
The "click jacking problem" is long gone by the way. 

> ::: apps/homepage/templates/homepage/teams.html
> @@ +58,3 @@
> >  <p class="highlight"><em>Don't find your Language?</em> You may want to check the list of
> >  <a href="https://wiki.mozilla.org/L10n:Teams">existing and upcoming teams</a> on our wiki, or
> >  <a href="https://developer.mozilla.org/en/Create_a_new_localization">start a new localization</a>.</p>
> 
> While you're at it, can you change this to
> https://developer.mozilla.org/en/Localization_Quick_Start_Guide ? The other
> link goes straight to an MDN edit as that page doesn't exist anymore :-/
> 
Fixed.

> ::: apps/homepage/views.py
> @@ +91,5 @@
> > +      'feed_items': feed_items,
> > +      'locales_first_half': locales[:split],
> > +      'locales_second_half': locales[split:split * 2 - 1],
> > +      'locales_rest_count': locales.count() - split * 2 - 1,
> > +    }
> 
> I'd prefer if we could do the locales query in one go, and just slice the
> resulting list.
> 
You're right! Being aware that our mysql isn't local helps. 
I managed to reduce it to some python list magic and thus 3 db queries is now only 1. 

Also, to back up my claim I moved it into its own function and added a unit test for it. 

> Also, for demo setups with 3 locales, we probably don't want negative rest
> counts? Either fix that here or in the template to only show that link if
> there's more than 0?

I made the above mentioned function "smart" so it'll reduce the default split if there's too few locales. I don't think we should worry about the rare cases when there's only like 1 locale. If it does become a real problem we can deal with it then. 

> 
> ::: apps/l10nstats/static/l10nstats/css/tree_progress.css
> @@ +56,5 @@
> > +
> > +.legend {
> > +    float: none !important;
> > +    margin-top: 10px;
> > +}
> 
> the float:none directly conflicts with the explicit style attr in the
> template,
> <div class="legend" style="float:right">
> 
:(
I blame myself for throwing Schalk into the deep end. 

I think Schalk got confused, in the beginning about what he could edit and tried to do it all by CSS.

As per our IRC discussion I've now fixed the legend. 


> ::: apps/pushes/templates/pushes/pushlog.html
> @@ -45,5 @@
> >  <link rel="stylesheet" href="{{ STATIC_URL }}css/jquery.ui/smoothness/jquery-ui-1.8.16.custom.css" type="text/css">
> >  {% endcompress %}
> > -{% compress css %}
> > -<link rel="stylesheet" href="{{ STATIC_URL }}pushes/css/style-gitweb.css" type="text/css">
> > -{% endcompress %}
> 
> Now that we don't use that file anymore, it should be git removed, I guess.
> 
Removed. 

> ::: apps/shipping/static/shipping/css/snippet.css
> @@ +80,1 @@
> >      }
> 
> hard-coding the width here sounds wrong. both that it's in px, when it's
> trying to align text, but also it should at least be a min-width, so that if
> we get an overflowing tree name, things still show.
> 
min-width does sound like a much better idea. That keeps things more fluid and yet achieves the alignment across tables (ie. across applications)

> A min-width in ex or so sounds much more like it.
> 
Why would "ex" be better than "px"? Isn't ex relative and px absolute? And isn't absolute something we want?

With "min-width:145px" I increased the font (like a sight impaired user would) and it "scales up" very nicely in Aurora. 

> ::: requirements/prod.txt
> @@ +10,1 @@
> >  
> 
> Should we have a follow-up bug to make all of these have explicit versions?
> 
The requirements/prod.txt is quite stupid. Nothing in that least isn't already in the vendor or vendor-local which is even more accurate than explicit version numbers in terms of predictable versions.

What we should do is nail requirements/compiled.txt but I don't feel like rushing it right now since things are working just fine. 

> ::: settings/local.py-dist
> @@ +46,5 @@
> >  # if you want to test the Arecibo
> >  #ARECIBO_SERVER_URL = "http://amckay-arecibo.khan.mozilla.org/"
> >  
> > +# Feed for example, to avoid having to do a HTTP call for the feed use:
> > +#L10N_FEED_URL = 'file://' + os.path.abspath('apps/homepage/test_rss20.xml')
> 
> is that fool-proof of starting elmo in non-standard directories, if that
> even works? wondering if some os.path.dirname(__file__) or something to make
> sure we get the right basepath would be at order?
> 
Yes I think so since it's calculated from the manage.py parent directory. 

> ::: static/css/style.css
> @@ +1,1 @@
> > +/*  Reset */
> 
> Nit, I don't know how many of the rules below are actually reset, and when
> we actually start a non-reset stylesheet.
> 
> Of course, I don't grok css reset to begin with :-(.
>
Good point. That looked like a "section header" and it was only really a comment for the next two selectors. I simply removed it now. 
 
> @@ +163,5 @@
> > +body#home > header {
> > +    height: auto;
> > +}
> > +
> > +/* new header */
> 
> Oy, header and new header? Just sayin', I bet most of this stuff is copied
> over from mozilla.org history.
> 
Fixed.

> @@ +525,5 @@
> > +/* Media Queries */
> > +/* Small screens */
> > +@media (max-width: 960px) {
> > +
> > +    /* { border: 1px solid red; }*/
> 
> debug? remove.
> 
Fixed.

> ::: templates/base.html
> @@ +50,5 @@
> > +    /* MetaWebPro font family licensed from fontshop.com. WOFF-FTW! */
> > +    @font-face {
> > +        font-family: 'MetaBold';
> > +	src: url('{{ STATIC_URL }}fonts/MetaWebPro-Bold.eot');
> > +	src: local('☺'), url('{{ STATIC_URL }}fonts/MetaWebPro-Bold.woff') format('woff');
> 
> sharing the font from mozilla.org didn't work after all? Cool with me, just
> checking.

That's what I got from Adrian and I assumed it was meant to be like that. Then, when I compared with www.mozilla.org/firefox I obviously got misled because that it actually on mozilla.org.

Assignee

Comment 35

•

12 years ago

Attached patch final patch with latest fixes — Details — Splinter Review

Attachment #597071 - Attachment is obsolete: true

Attachment #597885 - Flags: review?(l10n)

Reporter

Comment 36

•

12 years ago

Comment on attachment 597885 [details] [diff] [review]
final patch with latest fixes

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

r=me with the nits below. Nice job, thanks a ton.

::: apps/l10nstats/static/l10nstats/css/tree_progress.css
@@ +56,5 @@
> +    background-color: #E6E6E6; 
> +}
> +.my-timeplot { 
> +    height: 350px; 
> +}

I don't really know why, but this is not the same as the style attribute on the node. This makes the graph less tall, can you undo that?

@@ +65,5 @@
> +#histogram {
> +    margin-bottom: 20px;
> +    height: auto !important;
> +    clear: right;
> +}

We should also add a 

#histogram table {
    width: auto;
}

to overwrite the table:100% default that we added somewhere else.

No idea why the height: auto !important; is there, but that's all my fault.

::: apps/l10nstats/templates/l10nstats/tree_progress.html
@@ -86,4 @@
>  {% block content %}
> -<h1>Statistics for {{ tree }}</h1>
> -<p>String completeness for {{ tree }} localizations over time.</p>
> -<div id="my-timeplot" style="height: 350px;"></div>

... pairs the undo

::: settings/base.py
@@ +177,5 @@
> +L10N_FEED_URL = 'http://planet.mozilla.org/l10n/atom.xml'
> +HOMEPAGE_FEED_SIZE = 5
> +
> +## Number of locales to "preview" on the home page
> +HOMEPAGE_LOCALES_LIMIT = 12

I think it's cool to have that in a variable, but I really don't think we need to have this in settings. Having a variable in the view that one can monkey patch if absolutely needed is good enough.

Attachment #597885 - Flags: review?(l10n) → review+

Reporter

Comment 37

•

12 years ago

Seriously. Adjusting summary.

Summary: improve homepage, baby step one → improve homepage, leap for mankind

Assignee

Comment 38

•

12 years ago

Landed https://github.com/mozilla/elmo/commit/3baa008283fb1bf34fa79e5072ae7cb8de3561db

Also contained commits from other bugs:
https://github.com/mozilla/elmo/commit/fca512af719c9183b2fb08328de5191b72452102
https://github.com/mozilla/elmo/commit/05f8b96e148c1045769dc1c4cf72f165f76b974f

Status: NEW → RESOLVED

Closed: 12 years ago

Resolution: --- → FIXED