378677 - getfirefox.com and getthunderbird.com should redirect to localized product pages

Status: RESOLVED FIXED

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

Description

[Pascal Chevrel (relman team) -> :pascalc]

Currently, getthunderbird.com and getfirefox.com are redirecting to English product pages on mozilla.com.

These domains should redirect visitors according to their accept-language headers to the localized product pages we have on mozilla-europe.org and mozilla-japan.org

Comment 1

[Paul Kim]

What's the reason for this request Pascal?

Comment 2

[Samuel Sidler (old account; do not CC)]

Paul, is there a reason we *wouldn't* want to do this? If a user's primary language is set to something other than English, they probably want to see the web in something other than English.

Comment 3

[Pascal Chevrel (relman team) -> :pascalc]

Paul, I have received several requests from the French-speaking community to have getfirefox.com pointing to pages in the reader's language (in their case French) because getfirefox.com is used in the press as a generic official URL to download Firefox (probably because it is the URL mentionned in all Mozilla press releases).

getfirefox is also used on most of goodies from the international mozilla store, like posters, stickers, mugs...

So to me it makes sense to have our potential users access pages in their language, because most of the people we are now targeting, the non-geek audience, don't speak English.

Comment 4

[Paul Kim]

I asked for more information because I wanted to understand how the request originated. And also because we'll want to ensure before implementing this that the web analytics system we currently use, which tracks visits to getfirefox.com and getthunderbird.com that resolve to mozilla.com, will still provide meaningful data on visits to both URLs after we redirect to mozilla-europe.org and mozilla-japan.org. Last thing is, these redirects should be considered temporary as we continue to work with the web dev team on a unified web presence on mozilla.com for all product pages worldwide.

So thanks for the additional input - I'll follow up with our web dev team on this. I agree overall with the approach of providing localized content for non-en-US visitors.

Comment 5

[Paul Kim]

Adding clouserw and david rolnitzky to review for redirect implementation and to ensure our analytics software can be adapted to measure referrals.

Comment 6

[David Rolnitzky]

From an analytics point of view, if we redirect from a .com domain to a .org domain, we will lose the ability to tie those visits directly to a download of Firefox.  However, we will be able to see an increase in referrals from mozilla.com to mozilla.org.  

I think it will become increasingly important that we have a unified web presence, not just for consistent messaging across locales, but also so that we can tie our analytics systems together.  Currently, all of our separate domains operate in silos (whether that be add-ons, .org, .com, spreadfirefox, etc.)

Comment 7

[Pascal Chevrel (relman team) -> :pascalc]

David, I don't understand what you mean in your first paragraph, I don't understand why you talk about mozilla.org and mozilla.com referrals here, could you explain more about it?

As for the unified web presence, if mozilla europe and mozilla japan product pages, which BTW have already consistent messaging across locales, were already migrated to a multilingual mozilla.com, the problem would remain exactly the same: the Greek/Slovak/Basque... user clicking on a getfirefox.com link is not seeing a page presenting Firefox in a language he can understand and it is therefore unlikely that he installs our software.

if you want to comptabilize the links going from getfirefox to mozilla-europe, just use a double redirects, the first one being on the mozilla.com domain

getfirefox.com -> mozilla.com/{locale}/firefox/  -> mozilla-europe.org/mozilla-japan.org

This is the solution I was thinking of (with the transfer of the http-referrer value at each redirect to know from where people were coming before hitting getfirefox/thunderbird of course). When product pages are ultimately moved to mozilla.com, we just have to remove the second redirect.

Comment 8

[Wil Clouser [:clouserw]]

> if you want to comptabilize the links going from getfirefox to mozilla-europe,
> just use a double redirects, the first one being on the mozilla.com domain
> 
> getfirefox.com -> mozilla.com/{locale}/firefox/  ->
> mozilla-europe.org/mozilla-japan.org
> 
> This is the solution I was thinking of (with the transfer of the http-referrer
> value at each redirect to know from where people were coming before hitting
> getfirefox/thunderbird of course). When product pages are ultimately moved to
> mozilla.com, we just have to remove the second redirect.

We're doing this in several other places on mozilla.com with success (for example, http://www.mozilla.com/ja/firefox/ ).  It's a pretty simple solution and easy to maintain/change.  Depending on what David says, I'm in favor of adopting this solution.

Comment 9

[David Rolnitzky]

To clarify what I meant about .org and .com referrals:

Right now we are using Urchin analytics for en-US on Mozilla.com to track and attribute specific campaign activity and visit activity directly to a Firefox download. Because of the way Urchin works, in the past this has created problems in attributing downloads originating from one domain (e.g. moz.org) and ending up on another (e.g. moz.com).  

The problem happens with organic traffic that is not tagged with any campaign variables (e.g. mozilla.com/?_urchin-varibales-here).  Items that are tagged with campaign variables include Google Ad Words, banner campaigns, promotional landing pages, etc.  These items should not present a problem if we are redirecting to different domains as long as these urchin campaign variables are maintained in the url. But to avoid any problems with this, we should not use getfirefox.com for any online promotion and instead use moz.com, .org, etc.

So net-net: the solution that Pascal/Will have mentioned should be fine.

Comment 10

[Paul Kim]

Thanks David. Let's go for it then. Can we get this staged and tested before pushing live?

Comment 11

[Paul Kim]

clouserw: can you take this on? 

Comment 12

[Pascal Chevrel (relman team) -> :pascalc]

Wil, on mozilla europe we have two special urls :
http://www.mozilla-europe.org/firefox/
http://www.mozilla-europe.org/thunderbird/

These urls will redirect the visitors to the right product page for their language, for instance nn-NO and nb-NO users are redirected to :
http://www.mozilla-europe.org/no/products/firefox/

Comment 13

[Wil Clouser [:clouserw]]

Ok, so we've got 2 things we need to do, first is IT, second is me:

1)  Current redirects off getfirefox.com and getthunderbird.com are going directly to http://www.mozilla.com/en-US/firefox/.  We need to remove the language from there, so it should be going to http://www.mozilla.com/firefox/.  This will let mozilla.com pick the right language for the user based on their accept-lang headers.  (This should be doable right now, since if the page doesn't exist, they'll get en-US anyway).

2) Once those redirects are gone, we (the webdev team) can setup redirects for each language, like we discussed in comment #8.

So, off to IT for now, please give it back when you're done.  Thanks.

Comment 14

[Jeremy Orem [:oremj]]

I don't see either of those going to /en-US

Maybe someone changed it already?

Comment 15

[Wil Clouser [:clouserw]]

(In reply to comment #14)
> I don't see either of those going to /en-US
> 
> Maybe someone changed it already?
> 

I guess so - it's working the way we want it to now.

Comment 16

[Wil Clouser [:clouserw]]

Attachment: Adding redirects

Asking for r+ from pascal to verify all the languages that are supposed to be there are.

Comment 17

[Pascal Chevrel (relman team) -> :pascalc]

Comment on attachment 267104 [details] [diff] [review]
Adding redirects

Please also add these languages for redirects to mozilla europe:
nn-NO
sq-AL
en-GB

And remove es-AR, we only propose es-ES and Argentinian would probably prefer the other one.

Please also add ja and ja-JP-mac so as to point to Mozilla Japan. 

if paul is Ok, I would also be in favour of redirecting zh-CN users to mozilla.org.cn now that we have officialized our presence in China but checking their site they seem to not have updated their download script and still propose 2.0.0.3 to their visitors.

CCing gen to make sure he agrees with having getfirefox sending mozilla japan visitors.

Comment 18

[Gen Kanai [:gen]]

Yes, for any ja-JP or ja-JP-mac, we would appreciate redirects to Mozilla Japan.

Comment 19

[Wil Clouser [:clouserw]]

Attachment: after pascal's fixes

I added: nn-NO, en-GB
I removed: es-AR

We don't support sq-AL anywhere on the site, I'd have to add it to the languages array and create a new directory for it - is that what you're looking for?

ja has pointed to mozilla-japan for a long time already, so I didn't mess with it.

Comment 20

[Kohei Yoshino [:kohei]]

(In reply to comment #19)
> ja has pointed to mozilla-japan for a long time already, so I didn't mess with
> it.

Yes... I have secretly added redirects for product pages along with release notes (oh man!)
http://www.mozilla.com/ja/firefox/
http://www.mozilla.com/ja/thunderbird/

Comment 21

[Marek Stępień [:marcoos, inactive]]

Index: pl/firefox/index.html
===================================================================
--- pl/firefox/index.html	(revision 0)
+++ pl/firefox/index.html	(revision 0)
@@ -0,0 +1,4 @@
+<?php
+    header("Location: http://www.mozilla-europe.org/firefox/");
+    exit;
+?>

This means that if I'm using, say, French Firefox and enter a mozilla.com/pl/firefox URL, I will get the _French_ Firefox page?

It makes no sense to me, the mozilla-europe.org URLs should be the real ones, like http://www.mozilla-europe.org/pl/products/firefox/

Comment 22

[Pascal Chevrel (relman team) -> :pascalc]

Marek is right, using  mozilla europe shortcut urls was a bad idea, Wil can you update your patch with this change ? Thanks

Comment 23

[Wil Clouser [:clouserw]]

Attachment: Redirect directly to locale

Comment 24

[Marek Stępień [:marcoos, inactive]]

(In reply to comment #23)
> Created an attachment (id=267440) [details]
> Redirect directly to locale

This is wrong.

First, en-GB should be just "en", es-ES should be just "es", nb-NO and nn-NO should both be just "no".

And, the URLs should be in the form of http://www.mozilla-europe.org/xx/products/productname (e.g. mozilla-europe.org/pl/products/thunderbird) - currently the "products" directory is missing from the URL.

You haven't tested the URLs, have you? :)

Comment 25

[Marek Stępień [:marcoos, inactive]]

(In reply to comment #24)
> First, en-GB should be just "en", es-ES should be just "es", nb-NO and nn-NO
> should both be just "no"

...in the mozilla-europe.org URLs of course.

Comment 26

[Pascal Chevrel (relman team) -> :pascalc]

Comment on attachment 267440 [details] [diff] [review]
Redirect directly to locale

We use 2-letters codes on mozilla europe for languages and full urls contain /products/

nn-NO and nb-NO should go to :
http://www.mozilla-europe.org/no/products/firefox/
http://www.mozilla-europe.org/no/products/thunderbird/

es-ES to:
http://www.mozilla-europe.org/es/products/firefox/
http://www.mozilla-europe.org/es/products/thunderbird/

pt-PT to:
http://www.mozilla-europe.org/pt/products/firefox/
http://www.mozilla-europe.org/pt/products/thunderbird/

en-GB to:
http://www.mozilla-europe.org/en/products/firefox/
http://www.mozilla-europe.org/en/products/thunderbird/

Comment 27

[Wil Clouser [:clouserw]]

Attachment: Use 2 letter locales and add /products/

Comment 28

[Wil Clouser [:clouserw]]

Thanks Pascal.  Patch is in SVN, r4382.  You can see it at work on https://www.trunk.stage.mozilla.com/

Comment 29

[Marek Stępień [:marcoos, inactive]]

Verified with the trunk stage site.

See bug 383514 for a similar issue with links coming from AMO.

Comment 30

[Pascal Chevrel (relman team) -> :pascalc]

Reopening, I can see the changes on mozilla.com (ie http://www.mozilla.com/de/firefox/ redirects to the Firefox page on mozilla europe) but going to getfirefox.com or getthunderbird.com still redirects to http://www.mozilla.com/en-US/{product}/ only

Comment 31

[Paul Kim]

(In reply to comment #30)
> Reopening, I can see the changes on mozilla.com (ie
> http://www.mozilla.com/de/firefox/ redirects to the Firefox page on mozilla
> europe) but going to getfirefox.com or getthunderbird.com still redirects to
> http://www.mozilla.com/en-US/{product}/ only

clouserw: is changing the redirect behavior of getfirefox.com -> mozilla.com/en-US/firefox to getfirefox.com -> mozilla.com/xx-XX/firefox -> appropriate download page for a user's language something IT needs to help with?

Comment 32

[Wil Clouser [:clouserw]]

Hey Paul,

Actually, it's hitting a special redirect in the .htaccess.  When someone goes to just mozilla.com we're forcing them to en-US instead of detecting the language.  (The special redirect is in place to allow www.m.c to work without being redirected to en-us.www.m.c.

Anyway, it's obviously not expected behavior, so it's something I can fix.

Comment 33

[Wil Clouser [:clouserw]]

Attachment: detect locales rather than redirect to en-US

This patch:

- Removes the hardcoded redirect to en-US when no language is requested in the URL
- Removes adding $default_lang (in our case, en-US) to the start of the URL when falling back
- Changes the main redirect to use $_SERVER['SCRIPT_URL'] for redirects
- Adds a check around SCRIPT_URL to make sure we remove the language before redirecting to a new language.  This fixes a bug where going to /firefox resulted in a different redirection than /firefox/

Comment 34

[Paul Kim]

Thanks Wil. Can we test on stage before pushing to production? I can test from US, and if we can get Pascal for FR, and maybe Kohei from Japan that would be great. Plus other folks internationally with access to www.stage.mozilla.com.

Comment 35

[Wil Clouser [:clouserw]]

Paul, for sure.  I asked for review from reed before I commit it though.

Comment 36

[Reed Loden [:reed]]

Comment on attachment 269437 [details] [diff] [review]
detect locales rather than redirect to en-US

>-    // Forward them on to the right URI - this needs to be REQUEST_URI so it passes
>-    // parameters
>-    header("Location: {$config['url_scheme']}://{$lang}.{$config['server_name']}/{$lang}{$_SERVER['REQUEST_URI']}");
>+    // Do we need to preserve $_GET params?
>+    header("Location: {$config['url_scheme']}://{$lang}.{$config['server_name']}/{$lang}{$_SERVER['SCRIPT_URL']}");

This is the only change that concerns me... What if we decide we need to pass stuff in the future from the browser to the site? This would break that. I just dunno... Doesn't Remora pass _GET params like flang and such? I just don't see a reason to change this. Am I missing something that breaks because of this, or is this just general clean-up you are doing? Leave this as '?' until I get a response.

Comment 37

[Wil Clouser [:clouserw]]

Attachment: update redirects

Talked to reed on IRC.  We can continue to use REQUEST_URI to pass params

Comment 38

[Wil Clouser [:clouserw]]

Thanks reed - this is r4628.

Paul and everyone else:  Now that this and bug 384082 are fixed we have "real" language detection setup.  Please have a look at https://www.trunk.stage.mozilla.com/ to verify things work the way you'd all like.    Thanks.

Comment 39

[Paul Kim]

Nice work guys. Verified on trunk that behavior is as expected for an en-US visitor.

Comment 40

[Pascal Chevrel (relman team) -> :pascalc]

It works for me as well for French.

Comment 41

[Kohei Yoshino [:kohei]]

https://www.trunk.stage.mozilla.com/firefox/
-> https://ja.www.trunk.stage.mozilla.com/ja/firefox/
-> http://www.mozilla-japan.org/products/firefox/

Looks good.

Comment 42

[Paul Kim]

OK - I've asked IT to sync mozilla.com to make these changes live in bug 385706.

Comment 43

[Wil Clouser [:clouserw]]

Changes are live.

Comment 44

[Wil Clouser [:clouserw]]

In case someone tries this and sees that they're still sent to en-US, I've filed bug 385723 because the netscaler is caching a redirect that it shouldn't be.  Once that bug is fixed, this should start working properly.