393634 - Incorporate product-details into mozilla.com

Status: RESOLVED WONTFIX

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

Description

[Wil Clouser [:clouserw]]

This is in the production tag already, but is blocked from going live by an email discussion about what behavior we want to offer users:  the current mozilla.com behavior (locale offered is that of the browser) or mozilla-europe behavior (locale offered is that in the URL).

Comment 1

[Wil Clouser [:clouserw]]

We ran into problems with the new system here, because only one locale (en-US) is offered on mozilla.com.  Until we get more, we still want to offer lcoalized builds to visitors, even if they're looking at the en-US version.  Explanation from productDetails.class.php:

         * There are currently two sets of behavior for our download buttons:
         *
         * 1) Locale and platform are detected by javascript, and the best download we can give is
         *    offered in the green download button.  This means someone visiting http://www.mozilla.com/de/
         *    with an English browser will be given an English download (even if the content of the page
         *    is in German).
         *
         * 2) Platform is detected by javascript and locale is determined by URL.  This means visiting
         *    http://www.mozilla.com/de/ will offer a German download, no matter what locale the visitor's
         *    browser is in.
         *
         * As of this writing, mozilla-europe.org is using method #2, mozilla.com is using method #1.  Our
         * goal is to get both sites on method #2, however, since mozilla.com only has en-US on it right now,
         * we'd only ever offer users an English download.  Until we get translated content for other locales,
         * we'll have to revert to option #1 on mozilla.com.




When this bug is FIXED, download.old.js can be removed, along with any code marked 20070827_TEMP.

One other thing worth noting - Hebrew is the only language that currently has a /firefox/index.html file on mozilla.com.  I left it displaying only the Hebrew downloads.  Pascal suggested that only English have the dynamic download buttons - at first I wasn't in favor because it breaks consistency, but I'm warming up to the idea.  It sounds like we've got plenty of time to think about it - input is welcome.

Comment 2

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

I think that we should aim to have the best of both world.

We need easy maintenance because we have many pages with download boxes, not only because we have many locales but also because we also offer firefox downloads for special editions (ebay, kodak, campus...) and probably more in the future. Php brings this, with a couple of files to update for every minor release instead of dozains of pages, that would make the security firedrill much less work for the web team.

We need flexibility because we have many specific cases, the first specific case being that lots of people are using the en-US version just because their language is not currently supported.

What is clear to me is that the more languages we support, the more small teams we will get on board. I don't think we can realistically expect from a one-man effort to localize Firefox in a minoritory language to also maintain a web localization of mozilla.com, so some locales will never have web localization (apart from in-product pages) because their teams are way too small.

The javascript solution brings us this flexibility, detecting the preferred locale of the visitor and proposing this locale if we support it on mozilla.com/en-US. Of course javascript also has drawbacks: QA needed to make sure our script works in all browsers, depends on having Javascript activated and not filtered out by a firewall, bad for localization, caused an XSS attack in bug #357750 ;) )...

So I propose that the locale detection be added to the php version 

When we specify a language, the download box is in this language:
$firefoxDetails->getDownloadBlockForLocale('fr');

But if we give no language indication, it should mean 'detect the user's preferred locale from his HTTP-ACCEPT-LANG headers' and propose the download in this locale.

With this, we could ease the work on the web site with each minor release. Currently the 'no-locale' behaviour is the main behaviour, but even if we get mozilla.com localized in X languages, we will never have all of them and/or there will be a long delay between the product localization and the existence of the website in the same language, so this behaviour will be needed.

A third behaviour that would be nice would be to be able to pick up the language from this. mozilla.com/fy would redirect to mozilla.com/en-US/ but would display a download box in Frysk language (Dutch minoritary language). This would solve the problem for languages like frysk, afrikkans... which do not know how to give a simple download url to their users who are using Firefox into en-US or NL.

The two first beahaviours are I think a short-term solution to most of our problems, the third behaviour would be necessary now for a few languages and in the future as we march towards supporting more and more languages (because we now have most major languages so all the languages we will add now are smaller ones with less chances to find several volunteers).

Comment 3

[Wil Clouser [:clouserw]]

If we never have as many web pages as we do locales, we definitely need to do something to offer those locales to users.  Your first two ideas use PHP, which I'd rather not do, since it means more stuff that could break with our caching (we've got several pages that are never supposed to be cached right now, but every once in a while they show up cached).  It also means more work maintaining which pages need to be cached and which don't.  I'm adding oremj to the CC's to see if IT has any input.

What do you think of combining the two options - we provide the locale specified in the URL, and then do js detection, and if the browser's locale is not what is in the URL we display a second button under the first with the other locale?

I like your 3rd behavior as a long term idea.

Comment 4

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

I think that fixing our caching system so as that its bugs do not prevent us from using php would be the real solution :)

For the pages being cached or not, I was thinking of just having a parameter in the page like $cache = 1; and if this parameter is there add the right headers in prefetch.php (I guess http headers are set there, didn't look in details), not changing individual pages.

Your solution could work too, we could generate the javascript from the php class as well, but I don't really like multiplying download boxes because if we don't trust our caching system for language detection, then we don't trust it either for OS detection and we should also detect the OS via javascript.

Does the netscaler manages .php pages as well ? if not, we can just rename our download pages index.php instead of index.html so as to get back control on them and use php only.

Comment 5

[Reed Loden [:reed]]

(In reply to comment #4)
> Does the netscaler manages .php pages as well ? if not, we can just rename our
> download pages index.php instead of index.html so as to get back control on
> them and use php only.

I don't understand your thoughts here. We currently treat .html files the same way as .php files. There is no difference between the two extensions currently, so changing the extension won't help any.

Comment 6

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

my thought is that I guess the netscaler also works based on file extension like 'cache .gif files but nor .svg files' for instance, so if .php files can be entirely excluded from the caching system, instead of adding specific http headers to the .html pages we don't want to cache, we could rename their extension as .php.

Comment 7

[Justin Fitzhugh]

not caching is a very bad idea - it causes us to really load up our web servers.  I agree with Pascal in that we need to make sure caching works as expected, and developers have well defined ways of interacting with the cache.  Non-cachable pages are expensive and should be avoided when possible...