680147 - [l10n] FX Landing Page Experience

Status: VERIFIED FIXED

(www.mozilla.org :: General, defect)

Description

[mcbmoz]

Goals: 

*Increase FX downloads
*Create better user experience based on browser version detection (getting users to the information they need as quickly as possible)
*Take advantage of Greg's findings from Bug 659978 demonstrating a 6% increase in downloads.

Proposed Experience:

*Implement across all locales users of other browsers to https://www-trunk.stage.mozilla.com/fr/firefox/tests/abtest3.html 

*Implement across all locales users of 3.6 and below to https://www-trunk.stage.mozilla.com/fr/firefox/tests/abtest3.html 
* Implement across all locales users of 4.0+ to https://www.mozilla.com/de/firefox/ 

Website Resources Plan:

Implement browser version detection (easily done)

*Launch new simplified landing page (ex: https://www-trunk.stage.mozilla.com/fr/firefox/tests/abtest3.html with updated graphics (replacing glow data with the images on the current live pages)

*Keep existing template for up-to-date users (ex: https://www.mozilla.com/de/firefox/)

Questions? 

Thanks!
~cb

Comment 1

[Pascal Chevrel:pascalc (PTO until April 26)]

Adjusting the title since it affects all our locales on mozilla.com, not just European ones

Comment 2

[Pascal Chevrel:pascalc (PTO until April 26)]

Done in r94066 on trunk
RTL support for ar and he not done yet

Comment 3

[Pascal Chevrel:pascalc (PTO until April 26)]

r94067 fixes a php warning in strict mode

Comment 4

[Pascal Chevrel:pascalc (PTO until April 26)]

all the templating work is done and on trunk/stage/prod but only activated on trunk which has the htaccess necessary changes to activate it.

https://www-trunk.stage.mozilla.com/de/firefox/
https://www-trunk.stage.mozilla.com/de/firefox/new
https://www-trunk.stage.mozilla.com/de/firefox/fx

It works locally but not on trunk because I believe our caching mecanism caches the user agent of our visitors for locales, I haven't been able to find a technical solution today to that despite spending several hours on it and trying several approaches with Anthony. 

The htaccess code is there on trunk:
http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/.htaccess?view=markup&pathrev=94107#l302
lines 302 to 318

I believe http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/.htaccess?view=markup&pathrev=94107#l8 should be rewritten to be a regex matching the locale, otherwite the vary-ua environment variable is empty and we are caught in the caching system.

Given that I go on holidays tonight, that I am not very skilled with regex ;) and that this code is very sensitive for our en-US download page as well, I prefer to have webdev (James or Anthony for example) work on it quietly while I am away. Basically, everything will works once this htaccess change will be on production with the caching issue is solved.

Comment 5

[Gregory Jost]

Hey Anthony, a couple of questions for you:
- Have you had a chance to look into the regew issue Pascal mentioned yet?
- When this is resolved (see? I have no doubt in your ability to fix it!), will anything keep us from pushing this live?

Comment 6

[Anthony Ricaud (:rik)]

I haven't worked on this because our infrastructure to test it is not ready yet after the .org merge. This is depending on bug 682398 being resolved.

Comment 8

[Anthony Ricaud (:rik)]

I have something to test on www-dev.allimoz.org now.

Comment 9

[Anthony Ricaud (:rik)]

So http://www-dev.allizom.org/firefox/ seems to work (code is in prefetch.php).

But http://www-dev.allizom.org/{locale}/firefox/ does the good redirect but doesn't send the Vary: User-Agent header.

Comment 10

[Anthony Ricaud (:rik)]

So this works locally but not one the test website. So I think I'll need to sit down with IT during the all-hands to find a solution for this. Maybe the Apache version or the modules enabled or disabled explains the difference.

Comment 11

[Gregory Jost]

Thanks for this Anthony. Please keep us posted!

Comment 12

[Laura Forrest]

Hey Anthony - Any updates here?

Comment 13

[Anthony Ricaud (:rik)]

I need to sit down with Jake to find out why the Apache on my machine (and Pascal's) is not behaving the same way as the Apache for trunk and stage.

Comment 14

[Jake Maul [:jakem]]

All of the Vary header stuff I'm finding is done in .htaccess files... possibly you've got something in your VirtualHost config which is getting this to work?

If you get a chance, could you send it to me (or attach here)? I'll compare to ours and see what seems different. Thanks!

Comment 15

[Anthony Ricaud (:rik)]

Jake: Just sent you my vhost config files.

Comment 16

[Jake Maul [:jakem]]

Rik and I figured this out!

It's an Apache bug... kinda. The current documentation indicates that you can set an environment variable in a RewriteRule like this: [E=varyua,R=301].

That's not actually true until Apache 2.2.16... mrapp-stage04 (www-dev) is RHEL5, meaning it runs Apache 2.2.3. The new bedrock environment (Bug 652292) is RHEL6, but even that is only 2.2.15, so it won't work that way either.

In versions older than 2.2.16, RewriteRule will only set an environment variable if it has a value... E=varyua is insufficient and ignored. Presumably the documentation back then reflected this... hard to say.

The proper syntax is [E=varyua:1,R=301]. Set the variable 'varyua' *to* something, rather than just 'set' it.


You can see the changelog here: http://www.apache.org/dist/httpd/CHANGES_2.2 (skip to the 2.2.16 section for this particular issue).

Comment 17

[mcbmoz]

(In reply to Jake Maul [:jakem] from comment #16)
> Rik and I figured this out!
> 
> It's an Apache bug... kinda. The current documentation indicates that you
> can set an environment variable in a RewriteRule like this: [E=varyua,R=301].
> 
> That's not actually true until Apache 2.2.16... mrapp-stage04 (www-dev) is
> RHEL5, meaning it runs Apache 2.2.3. The new bedrock environment (Bug
> 652292) is RHEL6, but even that is only 2.2.15, so it won't work that way
> either.
> 
> In versions older than 2.2.16, RewriteRule will only set an environment
> variable if it has a value... E=varyua is insufficient and ignored.
> Presumably the documentation back then reflected this... hard to say.
> 
> The proper syntax is [E=varyua:1,R=301]. Set the variable 'varyua' *to*
> something, rather than just 'set' it.
> 
> 
> You can see the changelog here: http://www.apache.org/dist/httpd/CHANGES_2.2
> (skip to the 2.2.16 section for this particular issue).

HUUUUZAH! also fun to read about.

Comment 18

[Anthony Ricaud (:rik)]

Yeah, that was a fun debugging session :)

And so the good commit to fix this is r95589. I'll verify this tomorrow after a good night sleep and push if everything is ok.

Comment 19

[Gregory Jost]

(In reply to mcbmoz from comment #17)
> (In reply to Jake Maul [:jakem] from comment #16) 
> HUUUUZAH! also fun to read about.

I have rarely read a comment and understood so little ;)

Looking forward to get this live. Thanks guys.

Comment 20

[Pascal Chevrel:pascalc (PTO until April 26)]

Anthony, I am currently focused on my l10n work for the  State of Mozilla project + in an l10n-drivers meeting in Berlin today.

Could you wait for me to be back to Paris (around 21h00)  before launching, I'd like to be there when this is pushed live :)

Thanks

Comment 21

[Anthony Ricaud (:rik)]

Pascal: 21h on a Friday night? :) I won't be working at that time so that would mean Monday.

Comment 22

[Pascal Chevrel:pascalc (PTO until April 26)]

everything looks good to me on stage, you can push to production Anthony

Comment 23

[Anthony Ricaud (:rik)]

This is pushed to stage with r95747 and r95748. Please test on www.allizom.org.

Comment 24

[Anthony Ricaud (:rik)]

Pushed with r95753.

Everyone: please test this, it's a tricky change so…

Comment 25

[Gregory Jost]

Thanks guys!

Comment 26

[raymond [:retornam] (inactive)]

verified fixed http://www.mozilla.org/en-US/firefox/new/